This #ifdefs out the multiview for non-photon-theme, and checks for it being
present in various bits of JS that interact with it. As a result, this will
'fix' the issues in this bug and in bug 1370967 for 55 as it moves off
Nightly. bug 1370967 will still need fixing in the photonpanelmultiview /
webextensions.
MozReview-Commit-ID: 6x4HmyvxeRP
--HG--
extra : rebase_source : cdab2fab97795def95b6f4c70c61cfcb1c3ac2f9
This #ifdefs out the multiview for non-photon-theme, and checks for it being
present in various bits of JS that interact with it. As a result, this will
'fix' the issues in this bug and in bug 1370967 for 55 as it moves off
Nightly. By switching to the photonpanelmultiview, we get proper anchoring
and slightly improved styling (bug 1354086 covers the rest of that), even
where this code *is* enabled. bug 1370967 will still need fixing in
the photonpanelmultiview / webextensions.
MozReview-Commit-ID: 6x4HmyvxeRP
--HG--
extra : rebase_source : 11503543ab1945f82dc2ba902c32dd6092ebbe80
Post Project Dawn, for DevEdition, AppConstants.RELEASE_OR_BETA and AppConstants.MOZ_DEV_EDITION are true.
MozReview-Commit-ID: 7aQ4gOsIurT
--HG--
extra : rebase_source : cbfe652dffe8622c487a378268a7e8b1be501a9c
This ensures we update edit UI visibility state when opening/closing the
overflow panel, as well as ensuring we do so if/when the edit controls
get over/underflowed. It then updates the test to ensure we correctly
check the overflow panel, both for overflown items and for items
put there by the user when photon is enabled.
MozReview-Commit-ID: AjRH8wz5Pla
--HG--
extra : rebase_source : 706063645062f52333d5491907ea9ba857bcabe7
While we are now correctly evaluating the fullscreen situation
in OSX so that our update doorhangers behave as if we're in
windowed mode, we aren't correctly listening for state changes.
This addresses that, and tries to limit the chattiness by only
listening to the fullscreen events that we care about.
MozReview-Commit-ID: 9J009l4w21E
--HG--
extra : rebase_source : 4bcb607ec066b5cac390aac2dd649563d3b15beb
This caused regressions in various panels, like the Identity panel, resulting in
cut-off descriptions and labels. Our first concern is correctness, then we try
performance.
MozReview-Commit-ID: GH7BZ9waXeW
--HG--
extra : rebase_source : 82feb289936d99939ee664cf7b2aff32c1039b85
While we are now correctly evaluating the fullscreen situation
in OSX so that our update doorhangers behave as if we're in
windowed mode, we aren't correctly listening for state changes.
This addresses that, and tries to limit the chattiness by only
listening to the fullscreen events that we care about.
MozReview-Commit-ID: 9J009l4w21E
--HG--
extra : rebase_source : cfb6e65fe65f3b636212dcca95345f3ab7ea862e
This allows the panel to open correctly when scrollable views like History are displayed as the main view, for example when the History button is moved to the toolbar.
MozReview-Commit-ID: ELSbC0RpuaK
--HG--
extra : rebase_source : c1de4919c524c63f9ffdcda8576308fce223cad3
extra : amend_source : 5af3fe6044e23ccf4302cc2a8099afbd22fd1672
I updated, extended and refined Paolo's descriptionHeightWorkaround method to
support multi-line toolbar button labels.
Made the app menu use that method to ensure no scrollbars appear.
Also updated the styling of the banner to have icon and label align correctly
with those of the other buttons inside the panelview.
MozReview-Commit-ID: IzbahG0kyTu
--HG--
extra : rebase_source : 8a6c4e5ac7b1c0d30f53b732730629b5d8ca7166
On OSX we want to show doorhangers when in fullscreen, since OSX
fullscreen doesn't hide the nav toolbox. This makes that change,
and also adds flip="slide" to the panel so that the arrow adjusts
correctly. Unfortunately there still seems to be a bit of a
problem with this where the doorhanger adjusts its position when
entering fullscreen but then waits a little bit (not sure what
triggers it) before updating the anchor arrow. This is tracked by
Bug 1368094.
MozReview-Commit-ID: 3dRLwgMjxIb
--HG--
extra : rebase_source : 79ef7bcaed08829ed64f444d8506e94329518902
This also fixes two issues I found whilst writing the tests:
1. Exclude hidden items from the set of navigable buttons and
2. Exclude disabled items from the set of navigable buttons whilst navigating,
because they may get disabled in the meantime (like with the edit controls).
MozReview-Commit-ID: 5WThVoTZjbV
--HG--
extra : rebase_source : e0bd85192e7b1043ecf04b7d9d3b546aadb004c9
The height of the "panelmultiview" binding is now determined by the stack layout code, and doesn't have to be calculated manually via JavaScript anymore. This allows the removal of mutation and overflow observers, and reduces the number of synchronous layouts being made.
There is still a workaround included for wrapping blocks not being taken into account in height calculations.
MozReview-Commit-ID: 9rrPU5O5hUx
--HG--
extra : rebase_source : b872c14a553c4293ac476d5d22c634a5a0f6cb24
extra : intermediate-source : bf96469b6ea7daee29eb75a60d11f017a1c86a64
extra : source : 719bb4e7286fbd3baf32061929e4b7d9f953c671
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
--HG--
rename : browser/base/content/test/appUpdate/.eslintrc.js => toolkit/mozapps/update/tests/browser/.eslintrc.js
rename : browser/base/content/test/appUpdate/browser.ini => toolkit/mozapps/update/tests/browser/browser.ini
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindow.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindow.js
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindowFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindowFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPrompt.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPrompt.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPromptNoStaging.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPromptNoStaging.js
rename : browser/base/content/test/appUpdate/browser_updatesCantApply.js => toolkit/mozapps/update/tests/browser/browser_updatesCantApply.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadSizes.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadSizes.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesDownloadFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesDownloadFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesMalformedXml.js => toolkit/mozapps/update/tests/browser/browser_updatesMalformedXml.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchWithBadPartialSize.js
extra : rebase_source : 24048650b23eff0a1da9679d1e9b5e1db1900287
Right now, app menu doorhangers/badges have their state managed
directly inside panelUI.js. This is problematic because these
doorhangers and badges usually have to do with Firefox itself,
and not the specific window that's showing them. Accordingly, the
simplest solution was to move panelUI.js's notification state out
into a jsm file, which will fire notifications that all panelUI
instances can listen to.
MozReview-Commit-ID: 7b8w1WsQ29p
--HG--
extra : rebase_source : 23575df8176b862ec0e6a039173b105c45c76de9
