Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 7/22/14, 7:46 AM, milakam wrote: Guess it could be similar to the beforescriptexecute So you don't care if the script data is loaded (by the preload scanner), only whether it's executed? -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 07/21/2014 12:21 AM, milakam wrote:
Hi everyone,
A BeforeLoad replacement was never discussed as a target use case for
MutationObservers, therefore this message.
I'm currently creating a JS cross-browser user script and noticed that
only Chromium notifies the MutationObserver for an AddedNode before a
network request is sent (IE and FF don't and won't do anything with the
changes).
I found the following chromium discussion
https://code.google.com/p/chromium/issues/detail?id=18 which states
the MO as a replacement for BeforeLoad.
MutationObserver shouldn't be used as a replacement for any load related stuff.
MutationObserver is about mutations in DOM tree.
I think this is great solution
and it would be fantastic if it can be standardized.
No. It would disable several performance optimizations related to page loads.
-Olli
My own usecase / testcase I created:
script type=text/javascript
MutationObserver = window.MutationObserver;
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
var addedNodes = mutation.addedNodes;
for (var i = 0; i addedNodes.length; i++) {
if (addedNodes[i].nodeName == 'SCRIPT') {
addedNodes[i].src = 'good.js';
}
}
});
});
observer.observe(document, {childList: true, subtree: true});
/script
script type=text/javascript src=evil.js/script
In chrome this works out of the box and good.js is called directly
(without sending any network requests beforehand, if it would be stored
externally). In FF only evil.js is called. The source is updated
within DOM afterwards, but there's no network request or parsing of the
updated script (apart from the DOM change it has no effect).
In FF it's currently only possible with an internal extension like (e.g.
usecase
http://stackoverflow.com/questions/5330048/event-before-load-event-for-firefox-extension):
Components.classes[@mozilla.org/observer-service;1]
.getService(Components.interfaces.nsIObserverService)
.addObserver({
observe: function(aSubject, aTopic, aData) {
if (http-on-modify-request == aTopic) {
var url = aSubject
.QueryInterface(Components.interfaces.nsIHttpChannel)
.originalURI.spec;
if (url url.match('facebook')) {
aSubject.cancel(Components.results.NS_BINDING_SUCCEEDED);
}
}
}
}, http-on-modify-request, false);
I didn't test it in in Konqueror.
Greetz
MM
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
Boris That said, I can't reproduce the behavior you claim. http://jsfiddle.net/59Sxf/ alerts evil for me in Chrome. If the alert scripts are referenced as external js files it will alert good.js in Chrome. But I assume it's then a bug in Chrome that Data URLs are treated differently. Olli No. It would disable several performance optimizations related to page loads. Boris I think it would be terrible if registering a MutationObserver is forced to disable the preload scan (especially because you never know whether the MutationObserver will get registered at all until you start running scripts, at which point your preload scan is already going along), so I disagree with this being a great solution. Okay understood, bad idea ;) However, I think the problem remains. I'm fiddling with filtering and full control of what is displayed on a user PC since many years (starting with local proxies and then UserJS), still this doesn't seem to be very consistent cross different UAs: - Chrome dropped the event beforeload - Firefox has beforescriptexecute (but only for scripts, of course) Standard supported by all: - unload - counterpart: beforeunload - load - counterpart: ??? This doesn't sound too bad Safari 5.0 and later (and other WebKit-based browsers) generates a beforeload event before loading each subresource belonging to a webpage. The beforeload event is generated before loading every script, iframe, image, or style sheet specified in the webpage, for example. from https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9 Anyone knows why this never made it into the spec? Or are there alternatives? Sebastian
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 7/21/14, 12:42 PM, milakam wrote: If the alert scripts are referenced as external js files it will alert good.js in Chrome. http://jsfiddle.net/59Sxf/1/ seems to disagree. This doesn't sound too bad Safari 5.0 and later (and other WebKit-based browsers) generates a beforeload event before loading each subresource belonging to a webpage. The beforeload event is generated before loading every script, iframe, image, or style sheet specified in the webpage, for example. from https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9 Anyone knows why this never made it into the spec? How would this interact with a preload scanner, exactly? Or are there alternatives? Are we talking about web pages here, or browser extensions? -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 7/21/14, 1:13 PM, Boris Zbarsky wrote: http://jsfiddle.net/59Sxf/1/ seems to disagree. Er, sorry, I failed to actually test it in Chrome. And my original fiddle with data: URIs had a quoting issue which meant it wasn't testing the behavior. So I agree with you about what Chrome's behavior is. That said, Chrome's behavior is not useful for your purposes for script-inserted scripts, since those do prepare a script before the mutation observer fires... -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 7/21/14, 1:21 PM, Boris Zbarsky wrote: That said, Chrome's behavior is not useful for your purposes for script-inserted scripts, since those do prepare a script before the mutation observer fires... And for parser-created scripts I expect Chrome doesn't prevent the preload, but haven't tested that. -Boris
[whatwg] MutationObserver Spec for AddedNodes Timing network requests
Hi everyone,
A BeforeLoad replacement was never discussed as a target use case for
MutationObservers, therefore this message.
I'm currently creating a JS cross-browser user script and noticed that
only Chromium notifies the MutationObserver for an AddedNode before a
network request is sent (IE and FF don't and won't do anything with the
changes).
I found the following chromium discussion
https://code.google.com/p/chromium/issues/detail?id=18 which states
the MO as a replacement for BeforeLoad. I think this is great solution
and it would be fantastic if it can be standardized.
My own usecase / testcase I created:
script type=text/javascript
MutationObserver = window.MutationObserver;
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
var addedNodes = mutation.addedNodes;
for (var i = 0; i addedNodes.length; i++) {
if (addedNodes[i].nodeName == 'SCRIPT') {
addedNodes[i].src = 'good.js';
}
}
});
});
observer.observe(document, {childList: true, subtree: true});
/script
script type=text/javascript src=evil.js/script
In chrome this works out of the box and good.js is called directly
(without sending any network requests beforehand, if it would be stored
externally). In FF only evil.js is called. The source is updated
within DOM afterwards, but there's no network request or parsing of the
updated script (apart from the DOM change it has no effect).
In FF it's currently only possible with an internal extension like (e.g.
usecase
http://stackoverflow.com/questions/5330048/event-before-load-event-for-firefox-extension):
Components.classes[@mozilla.org/observer-service;1]
.getService(Components.interfaces.nsIObserverService)
.addObserver({
observe: function(aSubject, aTopic, aData) {
if (http-on-modify-request == aTopic) {
var url = aSubject
.QueryInterface(Components.interfaces.nsIHttpChannel)
.originalURI.spec;
if (url url.match('facebook')) {
aSubject.cancel(Components.results.NS_BINDING_SUCCEEDED);
}
}
}
}, http-on-modify-request, false);
I didn't test it in in Konqueror.
Greetz
MM
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
On 7/20/14, 5:21 PM, milakam wrote:
A BeforeLoad replacement was never discussed as a target use case for
MutationObservers, therefore this message.
MutationObservers happen when the DOM is modified.
Loads geneally speaking start off the preload scanner, before the DOM is
even constructed.
So you can't really use a MutationObserver to prevent loads, as you
discovered.
Obviously some UAs in some circumstances may delay some loads to after
the mutation observer is fired. That shouldn't be relied on.
I think this is great solution
and it would be fantastic if it can be standardized.
I think it would be terrible if registering a MutationObserver is forced
to disable the preload scan (especially because you never know whether
the MutationObserver will get registered at all until you start running
scripts, at which point your preload scan is already going along), so I
disagree with this being a great solution.
My own usecase / testcase I created:
script type=text/javascript
MutationObserver = window.MutationObserver;
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
var addedNodes = mutation.addedNodes;
for (var i = 0; i addedNodes.length; i++) {
if (addedNodes[i].nodeName == 'SCRIPT') {
addedNodes[i].src = 'good.js';
}
}
});
});
observer.observe(document, {childList: true, subtree: true});
/script
script type=text/javascript src=evil.js/script
In chrome this works out of the box and good.js is called directly
(without sending any network requests beforehand
Uh... That would be a clear spec violation. Toggling the src of a
script _after_ it has been inserted into a document (which is when
that MutationObserver fires) is a no-op per spec.
That said, I can't reproduce the behavior you claim.
http://jsfiddle.net/59Sxf/ alerts evil for me in Chrome.
The source is updated within DOM afterwards, but there's no network request or
parsing of the
updated script (apart from the DOM change it has no effect).
Right, as the spec clearly requires.
-Boris
