Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
The menuitem used to be only included in the markup for the non-browser window
case. This changes it to include it as a hidden <menuitem> for the browser window
case, and then unhide it for the non-browser window case.
MozReview-Commit-ID: 8tY3GiTFmqe
--HG--
extra : rebase_source : 4628aa160fefcb5eacad0e6b174be7216071bda1
The key used to be removed from the markup. This changes it to include
the <key> but instead disable it through the related command, which fits
the pattern used with other commands.
MozReview-Commit-ID: LPuwULDt22W
--HG--
extra : rebase_source : f463e41602b6c34c4cfcc2254d78647724117318
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 6372b2681a59d267f966e9fa2ca9a54e3ff0cea0
extra : intermediate-source : b11aa832c41ac5beef9065f804d11fb7c9887990
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 1e72949e4e1012025ccf87642cc239ea5f15217d
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
This notification fires when a browser window finishes running its idle tasks. Note
that it might never run if every window goes away before the idle tasks can run.
MozReview-Commit-ID: IEH98S29jhV
--HG--
extra : rebase_source : e15e496d5bd41a2ca2aaa170e3546491a9383ba5
This notification fires when a browser window finishes running its idle tasks. Note
that it might never run if every window goes away before the idle tasks can run.
MozReview-Commit-ID: IEH98S29jhV
--HG--
extra : rebase_source : c00e7053a3a18215a3549ea6fd7c7194dd4ca584
This removes the bookmark description UI, but leaves the backend in-place for a release or two, so that users have time to save anything they want (e.g. via backup).
The backend will be removed in bug 1402890.
MozReview-Commit-ID: La4AYFar7eK
--HG--
extra : rebase_source : 02bfe3cacdac331d09d5e62a1a70f48b68741670
This implements a new button in the identity popup that allows users to quickly
remove cookies and site data from the sites they're visiting.
This uses the SiteDataManager behind the scenes and is similar to the changes
we made for PageInfo already.
There's a major drawback to this approach in that SiteDataManager needs to
refresh its entire data set everytime we want information about a single site
or want to remove anything (it's not trivial to get rid of that limitation while
dealing with all the quirks of our storage APIs). I will work around this by
implementing a way for SiteDataManager to incrementally update itself in bug 1460768.
MozReview-Commit-ID: Iy7ia0KllFq
--HG--
extra : rebase_source : a36e0e7049c5892464d91ad42c3bf523dd5013f9
Extract logic around whether a browser needs to change processes, get a new
frameloader because of preloading, etc. from `_loadURI` in `browser.js` to
`E10SUtils.jsm` where it can be shared with other code paths.
The side effect paths (trying to handle in chrome, removing preloaded state) are
left behind in `browser.js` so that the `E10SUtils` version can be a pure
function.
MozReview-Commit-ID: 6LYB3e3U5o8
--HG--
extra : rebase_source : d6ecac045f90e62a374f8a100e3cc8e1f45f7527
Manually-implemented QueryInterface functions don't benefit from the
MozQueryInterface optimizaions, and a lot of them are in hot code, and
implement a large number of interfaces.
MozReview-Commit-ID: 8OzglraowZt
--HG--
extra : rebase_source : 5fff3d9973a0ea976096339a63ce9ff628b68441
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
***
Bug 1454202: Part 1a - Auto-replace uses of callback-based AddonManager APIs with Promise-based versions. r=aswan
This was done using the following script:
4cd5ae9597/processors/aom-api-generators.jsm
MozReview-Commit-ID: 8hobLz15a66
***
Bug 1454202: Part 1b - Manually fix eslint errors after auto-rewrite. r=aswan
This also deletes an obsolete test whose xpcshell variant was already deleted.
MozReview-Commit-ID: DM9W9Q2SVIE
***
Bug 1454202: Part 1c - Manually fix non-eslint issues after auto-rewrite. r=aswan
MozReview-Commit-ID: DtMscWZuExc
--HG--
extra : rebase_source : d4c2f80bdf02ec4a07e3713a9ae1823145d25942
I copied the browser.js contents to browser-siteIdentity.js, there are no changes.
MozReview-Commit-ID: AytWG2oijXc
--HG--
extra : rebase_source : 17e69c8aa92eeae866fc76d3669d3b551592f755
Tests are also added here for the legacy `getTopWindow` method to guard against
basic regressions.
We now start tracking browser windows right after the DOMContentLoaded event, which
is earlier than before. We now also assume that any newly tracked window has the
focus initially, which is closer to the nsIWindowMediator semantics.
MozReview-Commit-ID: 6QYJqA1tMPC
--HG--
extra : rebase_source : e04e567cf31d1a10e78647d75403b700bc65136b
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
Move all of the overlay pieces into an include file except for the
DTD's that could not be put there. Inline the DTD's into the files
where they were used. Update comments in macWindow.inc.xul and browser.xul
to more accurately reflect the current state.
MozReview-Commit-ID: HZIeSf29Yl
--HG--
rename : browser/base/content/macBrowserOverlay.xul => browser/base/content/macWindow.inc.xul
extra : rebase_source : 5772943e01b4c6de7526ab829c6ea5b6960016e5
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
Two fixes here:
updateAppearance really depends on the tabbrowser.xml updateVisibility(), so
make that dependency explicit and remove the event handling from tabbrowser.
After the previous patch, TabsInTitlebar.init() runs much earlier, which means
that the initialization check that bails out from update() is not taken. Turns
out that this is definitely not an edge case, and that tons of initialization
code all over gBrowser.onDOMContentLoaded call updateAppearance(true), causing
tons of extra invalidation and reflows that aren't really needed.
Ensure we only do the work once.
MozReview-Commit-ID: 2E9b12aBast
Not doing can it cause perf issues, but old Linux distros aren't really happy
about it, and they barf when the chromemargin is removed dynamically, so prevent
that happening by default.
Right now it happens on the resize we do right before loading the window, but
that will stop working after bug 1439875.
MozReview-Commit-ID: 1Rhaz07fHaY
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
--HG--
extra : rebase_source : 253bea4c4e90727c0e8cce4726bf7a695ca26d9d
extra : source : 4d6f855ea529f6043b3ca886f53901e16a3d6405
extra : histedit_source : b0aa76063dca7a85e43b3bf670aab8f185a57915%2C760885a660c4fd92e7ae777614ad3cdc84dc9b31
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
Move the main contents of editBookmarkOverlay.xul into an include file and
inline the DTD and CSS files where used. Convert several chrome tests to
browser tests since the preprocessor is hard to use within the testing
framework.
MozReview-Commit-ID: DpPBOpZSuBN
--HG--
rename : browser/components/places/content/editBookmarkOverlay.js => browser/components/places/content/editBookmark.js
rename : browser/components/places/content/editBookmarkOverlay.xul => browser/components/places/content/editBookmarkPanel.inc.xul
rename : browser/components/places/tests/chrome/test_bug427633_no_newfolder_if_noip.xul => browser/components/places/tests/browser/browser_bug427633_no_newfolder_if_noip.js
rename : browser/components/places/tests/chrome/test_bug485100-change-case-loses-tag.xul => browser/components/places/tests/browser/browser_bug485100-change-case-loses-tag.js
rename : browser/components/places/tests/chrome/test_bug631374_tags_selector_scroll.xul => browser/components/places/tests/browser/browser_bug631374_tags_selector_scroll.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_keywords.xul => browser/components/places/tests/browser/browser_editBookmark_keywords.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_tags_liveUpdate.xul => browser/components/places/tests/browser/browser_editBookmark_tags_liveUpdate.js
rename : browser/themes/linux/places/editBookmarkOverlay.css => browser/themes/linux/places/editBookmark.css
rename : browser/themes/osx/places/editBookmarkOverlay.css => browser/themes/osx/places/editBookmark.css
rename : browser/themes/windows/places/editBookmarkOverlay.css => browser/themes/windows/places/editBookmark.css
extra : rebase_source : aca072691251c1a44e82ab8091796abd2b140e22
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
textContent is used to set the indicator label text here instead of the value attribute because the text set using the value attribute does not wrap when it exceeds the width of the panel, which in turn pushes the menulist and half of the indicator text out of view.
MozReview-Commit-ID: 1VBaQlbZwzQ
--HG--
extra : rebase_source : 9bda7f5d8ec59b61dbc0e93c9a715c971ab5dceb
This resolves some confusion around the required callback for
`openInExtenalEditor` by converting it to instead return a Promise. This also
simplifies the flow of its callers as well.
MozReview-Commit-ID: EYoucELJLbu
--HG--
extra : rebase_source : b27541f6d86b06d967b6a5023d82c43efb422d67
We keep the XBL binding around for <content>, <constructor>, and <destructor>. This can
eventually be migrated to a Custom Element once we have platform support, but in the meantime
this is a way to get the many thousands of LOC into a JS class.
MozReview-Commit-ID: 1dCQp527yF9
--HG--
extra : rebase_source : 26b833413bab71168aa15e03f0f3803884be3f6b
extra : amend_source : 150cef6748ca8a9e819de0c674fac5966dd574cf
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
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