This changes the disk space notification to show the correct preferences path
and to use the correct openPreferences arguments.
MozReview-Commit-ID: BuKAUvDjp9T
--HG--
extra : rebase_source : 678f52801d100a980f529fc565d1009c38320ae4
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
Along with removing the view source standalone windows and prefs this patch:
1) Re-structures several of the view source tests that were only testing the old
standalone windows to now test view source in tab.
2) Adds support viewSourceUtils.viewSource() to open a browser window when there
aren't any open (for browser toolbox view source).
3) Cleans up some of the API for viewSourceUtils and removes the old deprecated
ways of calling it.
MozReview-Commit-ID: DI6sgZwbCf
--HG--
extra : rebase_source : 64677186122f74ab95912d5f3f173cf37472458a
We were not correctly setting the menulist value for default popup permissions,
which went largely unnoticed so far because the user had no way of actually setting
these permissions explicitly. It might happen with policy engine in the future
and so we should fix this.
MozReview-Commit-ID: 1VQc1NRGGX
--HG--
extra : rebase_source : 91dd30d11913316e1fc50c09b3ca37ae6430c938
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 will allow us to not rely on an actual <stringbundle> while still avoiding a mass rewrite
of code that accesses gNavigatorBundle with the more awkward API exposed by gBrowserBundle.
MozReview-Commit-ID: 2B4smbo1xZP
--HG--
extra : rebase_source : 0f2eef9178cb61802f158efe88b82a723f5e082e
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 moves the Safe Browsing notification banner into its own object, makes it aware of the current base domain,
and adds a function that's called when the location changes to determine if it should dismiss or not.
MozReview-Commit-ID: 31JQ4dUyFb4
--HG--
extra : rebase_source : e6d6589b0eef2d132fa355d4a6b36d2c429004af
extra : histedit_source : e385d8d7b609985ff29d8c9ff2d9ed55fc58bb85%2Ce8fb5de30938510a2b5d6a709b051e754a9ebc54
This enables whitelisted pages to send messages to the chrome using
asynchronous messaging from the content. This patch only adds the
API and test coverage. The first consumer of the API will be added
as part of bug 1417479.
MozReview-Commit-ID: ESxFFjvhpWA
--HG--
extra : rebase_source : 5f5183022134f87a64f830c084f84f7594b17b52
This enables whitelisted pages to send messages to the chrome using
asynchronous messaging from the content. This patch only adds the
API and test coverage. The first consumer of the API will be added
as part of bug 1417479.
MozReview-Commit-ID: ESxFFjvhpWA
--HG--
extra : rebase_source : 170677128c2d39c89f3a3bd76e201df4b3be8fb3
We apply a custom workaround to show about:home and about:newtab favicons
as early as possible for perceived performance, but didn't previously consider
the about:privatebrowsing page (which can act as both about:home and about:newtab).
MozReview-Commit-ID: gPiV08h0j0
--HG--
extra : rebase_source : 12a6ed0973013ed68e783ca3d39a9492c5185411
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
This sets the hardcoded favicon paths before painting the tab or window
to ensure they're painted right away.
MozReview-Commit-ID: 5V3gQP7XkNP
--HG--
extra : rebase_source : 1c887d035d031b5f2367d4599d18d4066282bbd5
The site security subview is now implemented using the "photonpanelmultiview" element, replacing the last instance of the "panelmultiview" element. The subview features a standard Photon header, hence the connection state icon was moved to the element below it. This makes the styles more similar between the main view and the subview. The connection state styles are now applied using a class name, and the tests have been updated accordingly.
This change required some fixes in the "photonpanelmultiview" implementation to make sure the height of the subview is correct and to allow keyboard navigation back to the main view.
Since the expander button and the permission controls in the main view are not visible anymore after the subview is shown, some code related to focus and hover could be removed as well.
MozReview-Commit-ID: 4nIAPWJPV8k
--HG--
extra : rebase_source : 74d6d769421c0f8521bdfae249b4d111e630a3bd
This patch adds a new diagnostic status flag to nsIWebProgressListener,
STATE_CERT_DISTRUST_IMMINENT, which indicates that the certificate chain is
going to change validity due to an upcoming distrust event. The first of
these events is this bug, affecting various roots from Symantec.
The STATE_CERT_DISTRUST_IMMINENT flag is set by nsNSSCallbacks and passed,
via nsSecureBrowserUIImpl, to browser.js where it is used to alert the console.
Adding this sort of diagnostic printing to be accessible to browser.js is a
long-desired goal, as future functionality can start doing more decision-making
there. We may, for example, also want to degrade the lock icon, which will be
straightforward with this flag.
This commit does not implement the IsCertificateDistrustImminent method. That is
follow-on work.
MozReview-Commit-ID: 75IOdc24XIV
--HG--
extra : rebase_source : e6a95d0be65f667eff0b131274272f0df91f8732
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 2qNWebBpsMY
--HG--
extra : rebase_source : b30a4492f839186584c074b82a1969973cda48e0
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 8wbjdYIC3gb
--HG--
extra : rebase_source : 2ea1b77d4a9fd9c3eb17853c8ec655b309a3fa8c
Setting an icon for the tab and storing that icon in Places are now separate actions.
Before bug 1401777 setIcon was doing both, but that was error-prone and more expensive.
Due to that change, useDefaultIcon stopped storing root domain favicons in Places.
MozReview-Commit-ID: Kt5xEXctsnU
--HG--
extra : rebase_source : 1ca4910915c26ee538d66e4a07d447e453c88d22
In the steps to reproduce of this bug, we get see a load start for about:blank that is not top level. We then see a following load complete (STATE_STOP) that has aWebProgress.isTopLevel=true. This code is really here to prevent flickering from reload->stop->reload for about:home and other about: pages. I don't see any harm in being more agressive when switching back to Reload since that is the default state.
MozReview-Commit-ID: 3LygnRLcbA9
--HG--
extra : rebase_source : fb73699a213765cdb9239a111a55848e513ab0ee
Setting an icon for the tab and storing that icon in Places are now separate actions.
Before bug 1401777 setIcon was doing both, but that was error-prone and more expensive.
Due to that change, useDefaultIcon stopped storing root domain favicons in Places.
MozReview-Commit-ID: Kt5xEXctsnU
--HG--
extra : rebase_source : f7fa2b0e818df2570f0078c86c4dfdaba3953f01
This patch covers two cases when loading a favicon:
1. Get the request context ID of the document load group, when <link rel="icon"> is found in the page.
2. Use the top level document's request context ID when using the default favicon.
* Swap margins for paddings around the searchbar when in a menu. Elements that could precede and follow the searchbar all have margin: 0, and define top/bottom padding as 4px, so this seems reasonable
* Harden the loop that looks up a matching ancestor - break before we hit the document
MozReview-Commit-ID: LuniL3gdLWR
--HG--
extra : rebase_source : 2101be3215ff85f2cf15ba624fad5256c92e40e8
* Swap margins for paddings around the searchbar when in a menu. Elements that could precede and follow the searchbar all have margin: 0, and define top/bottom padding as 4px, so this seems reasonable
* Replace the loop that looks for an appropriate trigger node to use element.closest. A click on the outside a toolbarbutton/item was climbing to the document node and throwing as it has no getAttribute method.
MozReview-Commit-ID: LuniL3gdLWR
--HG--
extra : rebase_source : b6f6cfa84b0d388c63bb3feea71100a38e26bb60
This code wasn't working properly due to the string check being broken, and if it worked it would be wrong when restoring a session rather than loading the homepage.
MozReview-Commit-ID: 7rEsRcBLg9N
--HG--
extra : rebase_source : 33d2a587b2394be1d0cc7a5273f55ce8064c0425