Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : 4d7f0880b2b4e8bd9424302bca16ef706e2fca25
This is a temporary measure until we have search complete and shipped (1353954).
MozReview-Commit-ID: KFeOefJ1RGM
--HG--
extra : rebase_source : 326a61f43e3e6f6d771b5bab713454945c9ee060
A couple other hidden="false" attributes were removed since they are unnecessary and shouldn't have been there. The changes to the downloadsGroup are because it is now nested inside of #applicationsContent.
MozReview-Commit-ID: IHZuKZUNYcR
--HG--
extra : rebase_source : f251849fd5a10bff8ad78554b96dc67c69a0ac78
The mercurial revision of sixgill listed in the manifest doesn't exist,
so I took what looks like corresponds to the last change to the tooltool
manifests, in order to avoid any other difference than GMP linkage.
This was built manually on a one-click-loaner.
--HG--
extra : rebase_source : 5ea830e48a6424a6ded9beab0628d0e562251c47
When panel behavior became asynchronous, |StarUI._doShowEditBookmarkPanel| needed to be changed to wait for the panel to finish opening before initializing it. Although the content of the panel can be changed successfully before the panel opens, the element focus at the end of initialization fails. This prevents the capturing of certain events, such as an Esc keypress (which should close the panel).
However, this introduced the problem where there is a short delay between when the bookmark panel opens and when the correct content is displayed in it. To fix this, the initialization function |gEditItemOverlay.initPanel| will now be called before the panel opens, but the element focus code will wait for the panel's popupshown event.
MozReview-Commit-ID: 6SrcCz963qW
--HG--
extra : rebase_source : c45f16913597b336dcae2717c0f902dbbe8025f2
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
MozReview-Commit-ID: JDJ3RtL4Lge
--HG--
extra : rebase_source : 7b49921bc653d57117f1c08212acc6c2db537984
extra : source : dd2d15dc577d9ec1ec16eb69d823c793dd1e9db0
Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : d0ddc7395115287620ed4c9532297e825996be1d
The browser.contentPrincpal will report a null prinicpal instead of the actual
content principal if the tab is not loaded. So the SessionStore will collect a
wrong principal for the 'iconLoadingPrincipal', and it will use this wrong
principal to load favicon when session restoring.
To fix this problem, this patch makes the TabState.jsm to collect
'iconLoadingPrincipal' from browser.mIconLoadingPrincipal which will be the
correct principal for loading favicon.
MozReview-Commit-ID: AYUbHFKaG8v
--HG--
extra : rebase_source : 3e2333f18c221d415bd0e26bc416a841344cef2c
The newer Theming API follows the WebExtension install flow, which uses
PopupNotifications to request permission before installation, show progress and
notify upon install completion. This patch makes sure that older LWTs follow that
same flow.
MozReview-Commit-ID: C7X2si0a47J
--HG--
extra : rebase_source : 76f6283818dd69f62c4d59b6b11c5e90d37145a2
Put back in line that was incorrectly removed previously, and add a test.
MozReview-Commit-ID: FEl8fT1uCDm
--HG--
extra : rebase_source : 549b4d9ab9c963ab5a92b81311cffe07fae6953c
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 0d794faebc8e751bfcd15476ae849018dfb1f6c1
