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
Based on a patch that Dão Gottwald <dao+bmo@mozilla.com> wrote.
We used to preload about:newtab as soon as a tab had finished being opened,
which meant that the first opened tab was _never_ preloaded, and that we
risked janking the browser immediately after the user opened a new tab
(which is, arguably, the worst time to do it, since the user is probably
about to navigate that tab somewhere).
This patch makes it so that about:newtab is preloaded after:
1) 1 second of user inactivity, and
2) When we have at least 40ms of idle time to spend in an idle callback.
The 1s and 40ms thresholds were chosen arbitrarily, and we might tune them
over time.
MozReview-Commit-ID: J5xkPQvCdW6
--HG--
extra : rebase_source : 51aed2f47ee5c6a68d04036d0bdc9e6357a5fc8d
