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.
