I have a script that does event.stop() and displays an alert on links.
Some of these links have other JS scripts linked to them, like tabs, accordions and so forth.
Of course my event.stop() doesn't always fire on them (the alert shows but the tabs etc. still work).
The project is quite big (many different plugins and JSes) and I'm wondering what's the best way of making my event.stop() always work before the other scripts do? Something like CSS !important.
Callbacks? For so many scripts?
You need to call event.preventDefault() or event.stopPropagation() like below:
$(selector).on('click',function(event){
event.stopPropagation();
});
Not: event.stop !
It's unclear from your question whether you're using PrototypeJS (which adds a stop method to events), or jQuery (which you've tagged, but which doesn't add a stop method on events).
But it doesn't really matter much to the answer: If the other handlers are attached to the element before yours is, there's no way for you to selectively prevent them being fired. You can remove them entirely (it may be hard or easy, but it's possible), but you can't stop them being fired.
If they're attached after your handler, then it's easy: Use Event#stopImmediatePropagation. jQuery adds it to event objects if the browser doesn't supply it; I don't recall whether PrototypeJS (which hasn't been updated in years) polyfills it for older IE or not. It does some of the others, but I don't know about that one.
Related
I understand that when you create a listener in jQuery Mobile like:
$('.this-class').on('swipe',tapHandler);
tapHandler will run twice. In order to eliminate this problem I have seen multiple solutions, such as:
$('.page-card').off('swipe').on('swipe',tapHandler);
or
wrapping it in side of pageinit in order to eliminate chaching issues if you are creating dynamic content within pagebeforeshow as seen here.
I also understand that even bubbling comes in to play here.
However, I was hoping that someone could explain why this known exists, and why the contributes to jQuery decided to take this route, knowing the drawbacks.
First lets discuss how jQuery Mobile works. Unlike normal web pages where jQuery is used jQuery Mobile uses ajax to load pages into the DOM, one or more pages can be loaded. Because of this, classic document ready is useless so jQM developers created page events.
Page events are major for this story. While document ready will trigger only one per page most of page events will trigger multiple times, depending on how much time page is re/visited.
Lets get back to on function (and all other similar functions like bind, delegate, deprecated live). Again when working on normal pages you will NEVER come to situation because same page will never stay in a DOM.
Here comes jQuery Mobile. If you are using a binding method inside a pageshow (or similar page event) that event will bind over and over. Basically on method was never intended to be used like this.
If you want to find out more about methods of prevention take a look at my other answer, look for topic: Prevent multiple event binding/triggering
I have a facebook connect button on this site here is the code
<fb:login-button onlogin="javascript:jfbc.login.login_button_click();"
perms="email,publish_stream,user_about_me,user_hometown,user_location,user_birthday,user_religion_politics,user_interests,user_activities,user_website"
size="medium" v="2"><a class="fb_button fb_button_medium">
<span class="fb_button_text"\>Login With Facebook</span></a></fb:login-button>
and i want to trigger this button with a javascript call and doing research i found this jquery that seems that it would do the trick (havent tested though) and i was wondering if there is an equivelent javascript or mootool because jquery is not installed. I can install it if i cant find a solution. Or if anyone has another idea on how to trigger this facebook button
$("fb\:login-button").trigger("click");
There are two ways to "trigger" a listener:
call it directly (e.g. element.onclick())
dispatch an event into the DOM that the listener will respond to
The trouble with the first method is that it doesn't replicate a bubbling event so the listener may not work as intended (e.g. there is no associated event object or bubbling, the listener's this keyword may not be correctly set).
The trouble with the second is that some browsers will not allow programatically dispatched events to do certain things (click on links for example). Also, in some browsers you have to use the W3C dispatchEvent and in others the Microsoft fireEvent.
So unless the listener has been designed specifically to work with one method or the other and is called appropriately, your chances of triggering the listener successfully are quite low.
PS. Some libraries provide their own event system, with custom events and bubbling of otherwise non-bubbling events, but in that case you have to set and trigger the listener using that library, otherwise it will probably not respond to either of the above methods.
You should be able to just invoke the same code that is invoked inline:
jfbc.login.login_button_click();
I suppose it would be something like
document.getElementsByTagName("fb\:login-button")[0].click();
I'm sure that would work very well with a "normal" DOM element that handles the click event; however, I'm not entirely sure it will work in all browsers with the fb:login-button element shimmed into HTML. You'll have to let me know.
Looks like you should be able to do:
document.body.getElementsByTagName("fb\:login-button")[0].click();
It looks like you want a namespaced element selector, so you should use:
document.getElementsByTagNameNS('fb', 'login-button')[0].click();
The : is the namespace separator.
I ran into this tonight, absolutely positioned a new button image over the iframe, and was planning on using pointer-events:none to pass through and click the iframe, but I was looking for a cross-browser solution, here you go.
jQuery('.button_fb_connect').live('click', function(){ FB.login() })
Your simply running the js function FB.login() after clicking your new element, obviously you can use whatever event you want.
Thats in jQuery of course, but thats the function you want, not just a simple click event trigger.
I have a grid and there is a column which contains <a> anchor tag with some additional information in <data-..> tag and has a class name <class='myspeciallink'>. And in my unobtrusive JS script I select all the elements with that class name and apply live('click'). I need that to be live() because the grid gets generated in the runtime.
What happens inside the live('click') handler? I use that additional data and add a <div> to the page based on that data. Which in its turn used to generate jQuery UI dialog. It works great on my computer.
But! How could that work in real-world? Should I be bothered about possible performance implications? I feel that applying live() on more than a dozen elements instantaneously
would affect the performance. Especially with rather complicated handler like mine - it needs to get the data, parse the data, create a div, apply a dialog and etc.
Does that smell like a bad design? Could you suggest a different approach or my concerns are unfounded? Can I use some sort of a profiler tool to find the bottlenecks in my javascript?
UPD: Still nobody suggested any profiling tool. firebug and chrome dev tools are good, but maybe there is something even better?
live("click") is actually better up-front from a performance standpoint: Instead of binding an event handler to each matched element, you're applying a single event handler which waits for events to bubble up and then sees if the element that triggered the event matches the selector .live was called on.
Compare this to $('selector').click(...) which does loop over each element and bind a new event handler. live('click') has no additional overhead regardless of how many page elements match its selector. Depending on how many elements your selector matches, using .live can avoid a delay of up to a few seconds during the initial load of each page.
However, the event handler must check each event which bubbles up against its selector, to see if there is a match. This is going to add a small amount of overhead to every click event, but chances are very good that your users will not notice the difference.
Peter bailey also has a nice post about this: Performance difference between jQuery's .live('click', fn) and .click(fn)
For my current project, I require the facility to be able to remove all functionality from a page, so that it is complete and literal static page. Removing the ability to follow any links, and disabling and javascript listeners allowing content to be changed on the page. Here is my attempt so far:
$("*").unbind().attr("href", "#");
But in the pursuit of a perfect script, and to allow it to work in every eventuality for any possible page (and with the uncertainty of a on liner being effective enough), I thought i'd consult the experts here at stackOverflow.
In summary, my question is, 'Can this be (and has it been) done in a one liner, is there anything this could miss?'. Please break this as best you can.
No. Nothing in this stops meta redirects, or timeouts or intervals already in flight, and it does nothing about same origin iframes (or ones that can become same origin via document.domain) that can reach back into the parent page to redynamize content.
EDIT:
The sheer number of ways scripts can stay submerged to pop up later is large, so unless you control all the code that can run before you want to do this, I would be inclined to say that it's impossible in practice to lock this down unless you have a team including some browser implementors working on this for some time.
Other possible sources of submarine scripts : XMLHttpRequests (and their onreadystatechange handlers), flash objects that canscript, web workers, and embedding code to run in things like Object.prototype.toString.
I did not want to write a lengthy comment so I'm posting this instead.
As #Felix Kling said, I don't think your code will remove the href attributes on every element but rather remove every element and then select their href attributes.
You probably need to write:
$("*").attr("href", "#").detach() ;
to remove the attributes instead of the elements.
Other than that, I doubt that you could remove the event handlers in one line. For one thing you would need to account for DOM level 2 Event registration (only settable with scripting) and DOM level 1 Event registration (via attributes or scripting).
As far as I'm concerned, your best bet is to make a shallow document copy using an XML parser and replace the old document (which you could backup-save to the window).
First: Your code will remove everything from the page, leaving a blank page. I cannot see how it would make the page "static".
$('*').detach();
will remove every element form the DOM. Nothing left. So yes, you remove every functionality in a way, but you also remove all the content.
Update: Even with the change from detach to unbind, the below points are still valid.
Event listeners added in the markup via oneventname="foo()" won't be affected.
javascript: URLs e.g. in images might still be triggered.
Event listeners added to window and document will persist.
See a DEMO.
I'm dynamically adding a lot of input fields through jQuery but the page gets really slow when reaching 200+ inputs (think of the page like a html excel sheet). This is fine really because this scenario is not very common. However, when I dynamically remove the input fields from the page using jQuery's htmlObj.remove() function, the page is still slow as if there were hundreds of inputs still there. Is there any way to explicitly free memory in jQuery/javascript?
My experience with this is from using Firefox. When using Internet Explorer, the page is really slow from the start but that's a whole different story.
The technique I'm using is called event delegation as it's supposed to be the least memory resourceful approach, compared to having all handlers explicitly bound to every object on the page.
Sadly, blur and focus events do not work with event delegation and therefore I need to bind these to every input. This could possibly be the memory hog here. Also, in Firefox it seems I can't use checkboxes for 'changed' or 'key[down|up]' events in event delegation as these checkbox events do not bubble up to the document. Here binding explicitly too.
Anyone can share some experience with this? Can't really show a demo right now as the site has not been launched yet.
Thx.
read this, I'm sure it will help.