11.0.41
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
This approach (document.write) does not work with XHTML or XML(SVG) files.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
Noticed that onload event attribute on body was not getting caught by the eventSuppressor. document.addEventListener() didn't even catch the event. Using plain addEventListener() did, but turns out load is non-cancelable. (https://developer.mozilla.org/en-US/doc ... load_event) That's not good.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
Please check latest development build,
v 11.0.42rc4
============================================================
x XML-compatible soft reload
v 11.0.42rc4
============================================================
x XML-compatible soft reload
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
Looks like special handling of onload in body needs to be done a bit later, so that it's certain the body has been parsed. DOMContentLoaded seems a good candidate. Doing it in a mutationobserver is also a possibility.
But it's not just onload. Also onunload and onpagehide share the same problem. There are likely others too.
For XML/SVG, inline and external scripts do not run allowed or not. Event attributes do fire, allowed or not.
But it's not just onload. Also onunload and onpagehide share the same problem. There are likely others too.
For XML/SVG, inline and external scripts do not run allowed or not. Event attributes do fire, allowed or not.
Code: Select all
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" onload="console.log('ONLOAD!')">
<script xlink:href="script.js" />
<circle cx="250" cy="250" r="50" fill="red" onclick="console.log('CIRCLE!')" />
<script type="text/javascript"><![CDATA[
console.log("SVG!");
]]></script>
</svg>
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
Could you check whether all these problems actually persist in Firefox 81?
Looks like they made the parsing much more regular and in line with what happens on Chrome (in facts, all the soft reload machinery seems unneeded there and I couldn't make it happen in latest RC where it's triggered on demand).
Looks like they made the parsing much more regular and in line with what happens on Chrome (in facts, all the soft reload machinery seems unneeded there and I couldn't make it happen in latest RC where it's triggered on demand).
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
Well, something did change with FF 81. The problem with events attributes on HTML page does not occur anymore with normal page reloads. It doesn't seem to happen on session restore or tab restore either, but it still does happen when navigating to another page and back.
NOTE: The other page needs to be about: page (e.g. about:newtab or about:config, but NOT about:blank). Navigating to and back from http: or file: pages does not exhibit the problem either. Likely because only about: pages cause the page to reload.
The underlying reason would appear to be that the "main thread" suspend in SyncMessage.js is effective again. But just most of the time as noted above. This is what I referred to with my comment about undocumented behaviour. It can change unexpectedly and unannounced. Extra care is needed if it's going to be relied on.
For XML/SVG files the behaviour is unchanged.
NOTE: The other page needs to be about: page (e.g. about:newtab or about:config, but NOT about:blank). Navigating to and back from http: or file: pages does not exhibit the problem either. Likely because only about: pages cause the page to reload.
The underlying reason would appear to be that the "main thread" suspend in SyncMessage.js is effective again. But just most of the time as noted above. This is what I referred to with my comment about undocumented behaviour. It can change unexpectedly and unannounced. Extra care is needed if it's going to be relied on.
For XML/SVG files the behaviour is unchanged.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
Please check latest development build, thanks.
v 11.0.42rc6
============================================================
x Document freezing to handle SVG and other XML documents
impervious to CSP on Mozilla
v 11.0.42rc6
============================================================
x Document freezing to handle SVG and other XML documents
impervious to CSP on Mozilla
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
Actually XML files are not impervious to CSP.
The problem is simply how to write the CSP as <head> has no special meaning in XML generally.
The situation is quite similar to as when we tried to write CSP to HTML in document-start and the head was not parsed yet. But now we do not even have anything to put the head in.
I bet you already figured where this is going.
Yes, we make the HTML document!
Naturally all the other problems that have plagued us on HTML still affect us on XML.
The problem is simply how to write the CSP as <head> has no special meaning in XML generally.
The situation is quite similar to as when we tried to write CSP to HTML in document-start and the head was not parsed yet. But now we do not even have anything to put the head in.
I bet you already figured where this is going.
Yes, we make the HTML document!
Code: Select all
let origDE = document.documentElement;
let newDOC = document.implementation.createHTMLDocument();
let tempDE = document.importNode(newDOC.documentElement, true);
document.replaceChild(tempDE, document.documentElement);
let meta = document.createElementNS("http://www.w3.org/1999/xhtml", "meta");
meta.setAttribute("http-equiv", "content-security-policy");
meta.setAttribute("content", "script-src 'none'");
// The newDOC has a head on the go, so we don't have to worry about that.
document.head.insertBefore(meta, document.head.firstChild);
document.replaceChild(origDE, document.documentElement);
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
Chromium doesnt need it: you can insert a propery namespaced HTML element in as a child of the <svg> element, and the <meta> csp you add there just work.skriptimaahinen wrote: ↑Fri Sep 04, 2020 5:07 am Actually XML files are not impervious to CSP.
The problem is simply how to write the CSP as <head> has no special meaning in XML generally.
The situation is quite similar to as when we tried to write CSP to HTML in document-start and the head was not parsed yet. But now we do not even have anything to put the head in.
I bet you already figured where this is going.
Yes, we make the HTML document!
Like what? Are there any remaining problems which have not a work around in rc6?skriptimaahinen wrote: ↑Fri Sep 04, 2020 5:07 am Naturally all the other problems that have plagued us on HTML still affect us on XML.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
-
- Master Bug Buster
- Posts: 244
- Joined: Wed Jan 10, 2018 7:37 am
Re: 11.0.41
Not familiar with XML/HTML namespaces enough to say which one is proper behaviour or if there is even any specification for this. Luckily this workaround is not too complex either.Giorgio Maone wrote: ↑Fri Sep 04, 2020 6:47 am Chromium doesnt need it: you can insert a propery namespaced HTML element in as a child of the <svg> element, and the <meta> csp you add there just work.
Was just referring to my little work around there.Giorgio Maone wrote: ↑Fri Sep 04, 2020 6:47 am Like what? Are there any remaining problems which have not a work around in rc6?
Have not had too much time to test rc6 yet, but initial tests say that no problems on FF81.
On FF80 only problem I have encountered is that onload on iframe fails to get caught, even though log tells me it is removed by the freezer.
Going to make further tests.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
In facts I'm incorporating it as a further safety net, thanks.
Giorgio Maone wrote: ↑Fri Sep 04, 2020 6:47 am On FF80 only problem I have encountered is that onload on iframe fails to get caught, even though log tells me it is removed by the freezer.
So there must be some difference in your file(s) which I'd like to check, thank you.
EDIT: I've probably found the difference by myself: if no <script> element precede the iframe, the onload event handler fires. Working on it...
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: 11.0.41
Please check #ldb#:
v 11.0.42rc7
============================================================
x Updated TLDs
x Let injected CSP prevent onload events from firing on
unfrozen embedded elements
x Work-around for applying DOM CSP to non-HTML XML documents
(thanks skriptimaahinen)
v 11.0.42rc7
============================================================
x Updated TLDs
x Let injected CSP prevent onload events from firing on
unfrozen embedded elements
x Work-around for applying DOM CSP to non-HTML XML documents
(thanks skriptimaahinen)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0