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
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
This adds workarounds to ensure that messages passed from browser.js
to content.js in the context of certerror pages always contain a frameId
which can be used to identify the frame that is supposed to receive them.
This fix is really meant to be temporary until we come up with a good
replacement for chrome - content communication, which probably boils down
to finding a middle ground between nsAboutCapabilities, RemotePageManager and WebChannel.
I did not update communication for Captive Portal pages, since those require
one-way broadcasting from chrome to content, which is not supported in this model.
This is tracked in bug 1446319.
I did also not change the behavior of the "Go Back" button, which still navigates
away the top level page, because I consider changing that behavior out of scope
for this bug (and in my personal opinion we should not change the behavior).
MozReview-Commit-ID: GrM6PFys6Cu
--HG--
extra : rebase_source : 135cd9abe570736b80587a018ba5caba59247e10
This adds workarounds to ensure that messages passed from browser.js
to content.js in the context of certerror pages always contain a frameId
which can be used to identify the frame that is supposed to receive them.
This fix is really meant to be temporary until we come up with a good
replacement for chrome - content communication, which probably boils down
to finding a middle ground between nsAboutCapabilities, RemotePageManager and WebChannel.
I did not update communication for Captive Portal pages, since those require
one-way broadcasting from chrome to content, which is not supported in this model.
This is tracked in bug 1446319.
I did also not change the behavior of the "Go Back" button, which still navigates
away the top level page, because I consider changing that behavior out of scope
for this bug (and in my personal opinion we should not change the behavior).
MozReview-Commit-ID: GrM6PFys6Cu
--HG--
extra : rebase_source : 5a49571b04b682bcde61e61f9874a25e405661f5
The context-menu change is technically not idempotent, since something like:
background-image: url(foo), linear-gradient(..);
Would throw before. But that didn't seem like a great deal to me.
MozReview-Commit-ID: 70pD1EyXDB
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
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This also ensures that we consider certificate error pages in frames as well as top-level.
MozReview-Commit-ID: IA4vT8yZnuN
--HG--
extra : rebase_source : c8825d4fc3e4a3ca018f27b2ada3a6bba2685a65
The link to the phishin-malware support site was hard-coded in bug 1363051 and bug 1359289. The links have been built through the urlFormatter.
MozReview-Commit-ID: FmKGcEM4GZd
--HG--
extra : rebase_source : bc73ff0d7ad87e9e5b36aa831a851e1aef443348
- fixing the hostName in getWindowInfo fixes the issue across the PageInfo panel
- fixing docInfo.referrer also fixes the Referring URL on the General tab
MozReview-Commit-ID: 9x9uWp2R3Yj
As our threattype-listname conversion design, "goog-harmful-proto" is allocated
for this new threat type. This threat type is mainly for mobile.
MozReview-Commit-ID: G9GbgmHHHfp
--HG--
extra : rebase_source : 0681fcd9322b94451a86eafe57bf1ccc4b89db30
extra : intermediate-source : 28b0502d9add81beeae58a2c33f9fd5839d4d544
extra : source : 646f02f15131aa98ad37015b0a641304a3271796
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14