11.0.41

Bug reports and enhancement requests
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

Please check latest development build,
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
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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.

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
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

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).
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

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
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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!

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);
Naturally all the other problems that have plagued us on HTML still affect us on XML.
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

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!
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 Naturally all the other problems that have plagued us on HTML still affect us on XML.
Like what? Are there any remaining problems which have not a work around in rc6?
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
skriptimaahinen
Master Bug Buster
Posts: 244
Joined: Wed Jan 10, 2018 7:37 am

Re: 11.0.41

Post by skriptimaahinen »

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.
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 Like what? Are there any remaining problems which have not a work around in rc6?
Was just referring to my little work around there.

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
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

skriptimaahinen wrote: Fri Sep 04, 2020 9:50 am Luckily this workaround is not too complex either.
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.
Could you please share your iframe test case? I did test for load/error events in any "loader" element, and that seemed to work pretty reliably (even though simple attribute removal was not as reliable as the suppressEvent() capturing handler, which indeed I reinstated after briefly trying to remove).
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
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: 11.0.41

Post by Giorgio Maone »

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)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
Post Reply