Do browsers remember events? - javascript

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.

Related

How to find the origin of a browser event

My web application started firing off a ton of events while idle and I've been trying to hunt down who has been firing them.
I received a Chrome performance profile from a client and discovered that the events are being fired from the root of execution. This makes me believe that the events are coming from the user. But the odd thing is, is that the events are being fired so quickly that it's impossible for a user to perform them.
I also doubt that these are being executed through the script or a timer because then the stack trace would be prepended with a timer fired or another function.
So now I'm at square one where I have reasons to doubt that a script is firing them and I have reasons to doubt that a user is firing them.
I'm going to reach out to my client and monitorEvents (https://developers.google.com/web/tools/chrome-devtools/console/events) on the element and then check to see if the event being fired isTrusted (https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted). If it is Trusted, then I have no idea what could be happening external to Chrome that's causing so many events. And if it isn't Trusted then I have no idea how to track the code that's firing so many events.
Zoomed in profile execution stack
Zoomed out profile execution stack

Why does 'stay on page' dialog pauses asynchronous function?

So this is really bugging me, I don't know if it is a browser related glitch or javascript just works that way ( I hope it does). I created a fiddle. https://jsbin.com/laluziqede/1/edit?html,js,output
Open your console, then click the button. When the dialog appears the function continues normally (first console.log isn't paused), however the one inside setTimeout function is paused and will only show after you click 'stay on page'.
But why, could someone explain this? I want to use this property in my application (execute an action right after user clicks stay), but I'm not sure if it's a good practice and is it working on all browsers and devices.
Edit: Here's the code from the bin:
$(window).on('beforeunload', function() {
return 'Check your console please and then click stay';
});
$('#click-me').on('click', function() {
window.location.href='about:blank';
console.log ('dialog won\'t stop me from showing');
var timer=setTimeout(function() {
console.log('this was paused by the dialog');
},0);
});
The behaviour is browser dependent. I tested it in Firefox, Chrome, IE and Edge, and of those only Chrome has the behaviour that you describe.
The difference lies either in when the beforeunload event is triggered, or when it is handled. Most browsers trigger the event immediately when you change the location property and also handle it immediately. Chrome either triggers and handles the event when the navigation is actually about to happen, or places the event on the queue and handles it later just like regular events.
In Chrome the code inside the setTimeout handler will not happen until after the beforeunload event is handled, either because the navigation is handled before any queued events, or because the timout event is after the unload event in the queue.
Javascript is single threaded (unless you start using things like WebWorkers and other newer technologies). So the timer function schedules something to be done, but it will only be done when everything else has yielded control of the javascript thread. So timer is only asynchronous in the sense that you're asking for some work to be done after some period of time, but it is not truely asynchronous in the sense that that something can be done while something else is also being done.
This applies to things like XHR requests as well, even though the XHR request are indeed dispatched asynchronously, the responses are all handled synchronously one at a time.
Your specific example is a bit odd in that it's not another javascript function that is blocking, it's a browser security feature that is making sure you want to let the previous javascript operation take you away from the current page. The concept is the same though.

requestAnimationFrame - Tell when browser loses focus

From what I have read requestAnimationFrame can tell when the browser loses focus. Is there some kind of event that fires when this occurs? I'm looking to pause and resume code in connection with requestAnimationFrame.
requestAnimationFrame is not an element on which an event can be or is fired when the browser loses focus; it just sets up a callback. But standard behavior is that when the browser/tab goes out of focus, callbacks are paused. Therefore, most likely your code (if in a callback) is already being paused.
There is a possibility that all browsers may not pause callbacks, but instead slow them down. However, the W3C spec would seem to imply pausing, not slowing:
Whenever a Document's hidden attribute ([Page Visibility]) is false and the animation frame request callback list is not empty, the user agent MUST regularly queue a task...
If d's hidden attribute is true, continue to the next entry in the contexts list.
If you want to be absolutely sure your code is pausing when the tab is out-of-focus, or if the code you are trying to pause is not structured as part of a RAF callback, then you could consider using the
Page Visibility API.
Note that both RAF and Page Visibility API are available only in IE>=10.

What's the difference between "DOMContent event" and "load event"

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

DOMContentLoaded is not getting triggered while visiting few sites. Any workaround?

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

Categories