This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
Currently, if you try to use contentDocumentAsCPOW, you'll get an
exception saying that browser code is not allowed to use CPOWs. That's
because we cleverly tried to get the CPOW via
contentWindowAsCPOW.document. However, this property access happens
inside remote-browser.xul, where CPOWs are forbidden. So it doesn't
work.
MozReview-Commit-ID: ANWad4tvGpU
Currently, if you try to use contentDocumentAsCPOW, you'll get an
exception saying that browser code is not allowed to use CPOWs. That's
because we cleverly tried to get the CPOW via
contentWindowAsCPOW.document. However, this property access happens
inside remote-browser.xul, where CPOWs are forbidden. So it doesn't
work.
MozReview-Commit-ID: ANWad4tvGpU
Currently, if you try to use contentDocumentAsCPOW, you'll get an
exception saying that browser code is not allowed to use CPOWs. That's
because we cleverly tried to get the CPOW via
contentWindowAsCPOW.document. However, this property access happens
inside remote-browser.xul, where CPOWs are forbidden. So it doesn't
work.
MozReview-Commit-ID: ANWad4tvGpU
What happens is the following:
- browser-child.js sends a statechange up to RemoteWebProgress.jsm that contains
a `documentContentType` value of `null`, along with `requestURI` and `originalRequestURI`
_after_ other state changes that did send a valid content-type.
- The content-type is used by the WebProgressListener in browser.js to toggle the
disabled state of the 'isImage' broadcaster.
- The 'isImage' broadcaster is used by the 'cmd_find' and 'cmd_findAgain' commands to
determine whether they should be enabled. In this case: not.
The fix here is to _not_ set the documentContentType in the browser binding when
it's `null`.
MozReview-Commit-ID: IELoCrnOH0j
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
Unfortunately, when onLocationChange is fired for an attack site for
the about:blocked error page that we display, content.document has not
been updated with the loaded error document, so
content.document.documentURI will appear to be the previous page that
had been loaded. In this patch, we update the parent's cache of
documentURI in onStateChange as well, since this seems to be fired
after the error page has been loaded.
MozReview-Commit-ID: 1yLAw0JTEC6
The browser.isSynthetic property is needed by the zoom code to detect when to
apply the correct zoom level. In e10s it is currently only set when a new
document is created which means we don't set it right for history navigation.
This sends it with the Content:LocationChange message which is where it is
needed by the zoom code anyway.
When swapping docshells we also have to swap any properties on remote-browsers
that are cached from the content process. This includes things like the
remoteWebNavigation etc. which in turn cache content information. Some of
these also maintain message listeners that we have to switch to the new browser
and message manager.