I have a page with javascript.
In $(function() {}); Everything works fine except for a couple clients with web-proxy, it doesn't work.
Digging into the problem, I found that DOMContentLoaded event is not firing at those clients (Google Chrome).
Is there way to find out reason which prevents firing of event, or getting pending event list ?
Also is there a way to listen to any events which fire before DOMContentLoaded ?
Related
In my Rails site, I have an element that I want to act as a link when clicked by a mouse (e.g. on a desktop), but not when touched on a touch-screen device (because there is also a hover behavior).
My understanding is that the JQuery .click event should not get triggered on a touch.
My coffeescript for setting the click handler is simply
...
$(this).click ->
location.href = url
...
(where "this" is the element in question)
I know this code works, because the click action works with the mouse. To ensure that it doesn't get triggered on a touch device, I use the device emulation in Chrome's Developer Tools to emulate a touch. However, when I do this, the method still fires and follows the link.
Is this a problem with the Chrome emulation or with my code? I want to know whether it will behave this way on real touch devices.
edit: Same thing happens with Firefox, so I'm thinking it's my code...
I realized that touch events trigger click events as well, later on in the event chain. To get the functionality I wanted, I kept the .click handler, but added a .touchstart handler where I called event.preventDefault() to short-circuit the rest of the event chain. This way, the .click handler fires for mouse clicks, but not for touches.
I would like to know what the browser does about events that happen while scripts are currently running. Does the browser just ignore these events or does it store them and execute them after any scripts stop running? Is this dependent on the event? I am specifically interested in mousemove and drag events.
Thanks
What do you mean? Events that trigger javascripts?
If so then yes, the triggered script is remembered and put on the call stack.
Javascript is single threaded -- so an event that triggers a new script will have to wait until all other scripts on the stack are completed before it fires.
So if your drag or mousemove trigger a script then that trigger will be remembered.
I've made a little experiment with Html5 canvas and Javascript events.
Unfortunately, in a certain case, the javascript click event has an unexpected behavior.
This is the fiddle of the experiment : http://jsfiddle.net/Rh4kP/10/
When you click, often there is no output in the console. I observed this on Google Chrome 22.0.1 and Firefox 14.0.1
More weird, when you comment one of the "flip" line like this :
document.getElementById(hiddenCanvas).style.display = 'block';
// document.getElementById(displayedCanvas).style.display = 'none';
or
// document.getElementById(hiddenCanvas).style.display = 'block';
document.getElementById(displayedCanvas).style.display = 'none';
Click events work propertly !
The definition of a click event is this, per the Mozilla Development Network:
The click event is raised when the user clicks on an element. The click event will occur after the mousedown and mouseup events. [emphasis mine]
In other words, your 'flip' event is firing so quickly modifying content that your mousedown and mouseup events are not happening on the same DOM element, and so click does not fire.
Try this example (derived from yours) to see this in action. You'll notice that when your click event fires, the mousedown and mouseup events happen on the same DOM element. But when it doesn't happen, it is because mousedown and mouseup are happening on different DOM elements. Another test to run is slowing down your flip/flop. With a very slow timeout, you'll have less of a chance of encountering this problem (though the chance still exists - I would recommend using mouseup)
Try using just the 'mouseup' event instead. I tested w/ your example and it seemed to consistently work.
See the If you delete a DOM element, do any events that started with that element continue to bubble? question for some more information.
In chrome's Developer tool, the blue vertical line labeled "DOMContent event fired", and the red line labed "load event fired". Does "DOMContent event fired" means the browser begin to execute the inline javascript? And "load event fired" means it fire "onload" event?
"DOMContent Event" is from webkit (which chrome relies on) and is equivelant to DOMContentLoaded msdn mdn.
The DOMContentLoaded event fires when parsing of the current page is complete; the load (onload) event fires when all files have finished loading from all resources, including ads and images. DOMContentLoaded is a great event to use to hookup UI functionality to complex web pages.
See the demo here, related question.
The DOMContentLoaded event is fired when the document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading (the load event can be used to detect a fully-loaded page).
The DOMContentLoaded event is fired when the document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading (the load event can be used to detect a fully-loaded page).
check Difference between DOMContentLoaded and Load events
I am developing a Firefox extension. My extension needs to get notified when a page completes loading. To implement this I am using DOMContentLoaded event. This works fine most of the times. But while visiting few sites (like nytimes.com), this event is not getting triggered at all. I am not sure whether these sites are using some special scripts.
Is there any workaround for this? Or is there a better way to implement what I am trying to do?
DOMContentLoaded may not be what you need...
According to MDN
Fired at the page's Document object when parsing of the document is
finished. By the time this event fires, the page's DOM is ready, but
the referenced stylesheets, images, and subframes may not be done
loading; use the "load" event to detect a fully-loaded page.
https://developer.mozilla.org/en/Gecko-Specific_DOM_Events
So, it is possible that nytimes.com and others my be using frames or complex CSS and that is why you are not getting the correct trigger.
As mentioned above, the "fix" is to
use the "load" event to detect a fully-loaded page