Because we generate IDs for special nodes, we should update the inDefaultState getter to actually consider
these nodes to match even when the ids differ. This wasn't an issue before because specials weren't in the
default set for any nodes.
MozReview-Commit-ID: AI85yt2LuJD
--HG--
extra : rebase_source : 819e27885148deb588c057c4e811371a87f1d2fc
We spend a lot of time at startup generating exception objects while trying to
retrieve nonexistent localized properties from string bundles. Since extension
widget values will never be localized this way, we should skip the string
bundle lookup entirely.
MozReview-Commit-ID: L9r59bf2Dgf
--HG--
extra : rebase_source : 04eb6f9a78215d0268d2eaee7f94fd5b4cff498b
* Use new panel animation when opening arrow-panels (including bookmarks menu) to fade in and drop into position
* Linux/GTK is (still) excluded
* New animation is non-directional (i.e. LTR vs. RTL)
This was landed then backed out due to test failures. New since last review:
* Make opacity & transform transition durations equal - ensuring popup is not still moving when popupshown is fired
* Fix missing comma in transition-duration values
* Add animating attribute to the arrowpanel binding to disable pointer-events during the opening transition (via :jaws)
* Wait for popupshown rather than transitionend in bookmark reparenting test
* Fix specificity of CSS rules for panels/bookmarks-menu on edges other than the top (via :jaws)
MozReview-Commit-ID: DTnvyMryf5Y
--HG--
extra : rebase_source : 77895818356b1b366e93c6a8c508ae2b74dbca5c
Prior to this patch, both CustomizableUI itself and the PanelMultiView module
tried to ensure that onViewShowing/Shown/Hiding/Hidden listeners were invoked
when the relevant DOM events fired.
PanelMultiView was doing this manually because CUI was only adding listeners
once the corresponding widget was created. Now that the relevant views can be
accessed without the corresponding widgets (via the fixed appMenu), there was
no guarantee that the listeners would be attached, and this caused empty
subviews.
Unfortunately, if the widget *was* present, it caused events to fire more than
once, which understandably broke consumers like the sync remote tabs widget,
which broke the test we're fixing up here. For other views, even if they were
not completely broken it at least did busy-work.
This patch removes the manual event invocation, and delegates the event
listener work to CUI from the PanelMultiView side. This ensures events fire,
and fire only once.
MozReview-Commit-ID: 94GhcrdcBuB
--HG--
extra : rebase_source : 4df42939aa06ec10b7f86c3c2e4fe75160c7e7bd
There are no more help/quit buttons in the panel that shows up in customize mode,
and there are no more hyphenation quirks in items in the panel, so those tests
have been removed. The remaining tests are updated to test the correct panels.
MozReview-Commit-ID: LiUWejjZC7c
--HG--
rename : browser/components/customizableui/test/browser_photon_customization_context_menus.js => browser/components/customizableui/test/browser_customization_context_menus.js
extra : rebase_source : 49cef6ebeee140aefdb7a90d64b48c0da8179dc1
The new panel doesn't have placeholders, or a distinction between wide and
narrow widgets, so those tests can just be removed.
MozReview-Commit-ID: D61AjwMbabG
--HG--
extra : rebase_source : 662a74e50ea05c5a4c5fdee476cae10fc9862775
Again, this test is mostly useless now, so I would also be fine with just removing it.
MozReview-Commit-ID: BwOGQ5pwSQd
--HG--
extra : rebase_source : 1e5b961e4f0f9f17d0aee3e6cd3aeb1d6bc75741
This patch changes the history-panelmenu widget with the following:
- Move the Recently Closed Tabs and Recently Closed Windows lists into their own
respective (nested) subview,
- Add a Recent History header to list of history items,
- Extend the list of Recent History items to be max 42 items long,
- Share more code with Bookmarks panel,
- Generalizes panelview event dispatching to always support customizable widgets.
MozReview-Commit-ID: 4sBR6llIvxG
--HG--
extra : rebase_source : 2758dd643cd504448ee1f19296670a588bf56069
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
Apparently the hover state of the combined buttons does not interact well with the menus unless they
share the same containing popup/panel. We broke that condition in bug 1354078. The expedient thing
is to simply move the popup back, and move it back and forth if/when the photon pref is flipped.
When removing the pref, we can simplify this by always putting the menu in the overflow panel.
I also noticed that we use the toolbar context menu in the dynamic portion of the overflow panel.
This has the same problem, and to fix it I switched us to using the same (panel) context menu in
the photon case. Doing this in the non-photon case won't help because the context menu will be in
a separate panel (namely the old hamburger panel) entirely.
MozReview-Commit-ID: 4neHMukTzHA
--HG--
extra : rebase_source : e9f18996383eb7e249dc17b0dc1a84bb6ce3f11d
This is a follow-up to the previous patch, required because on Windows we cannot measure the full height of the main view until it is visible.
MozReview-Commit-ID: 2pfYwMLPYIb
--HG--
extra : rebase_source : 0391a619f551b5e100688ea231d12ac26e0868c8
This animation can be disabled if the toolkit.cosmeticAnimations.enabled pref is set to false.
MozReview-Commit-ID: DtsrI8YflYn
--HG--
extra : rebase_source : 066dc736dc75489bf6ad787811d4ae34f03ed24f
This patch changes the Recent Bookmarks flow in browser-places.js to use the new
PlacesPanelview to provide a rich view that support drag and drop and context
actions.
A new button 'Search Bookmarks' was added, which prefills the urlbar with '* ',
which is a shortcut for searching bookmarks using the Awesomebar.
MozReview-Commit-ID: 1XlO8HMKEJs
--HG--
extra : rebase_source : 59cdf8a24341eb5df55511c5be83ebee8787aad5
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
--HG--
extra : rebase_source : 3a9ea310d3e4a8642aabbc10636c04bfe2e77070
These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
--HG--
extra : rebase_source : 0bf4fc4effc9de9e431ee50dfcf5fc7206e252cf
This also adds the icons in non-photon. They seem to work fine there, so I don't think this is a problem.
MozReview-Commit-ID: GkvT3i2jnD1
--HG--
extra : rebase_source : 80d33d329b5740328aa82dd5401475264700e57a
These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
--HG--
extra : rebase_source : 0bf4fc4effc9de9e431ee50dfcf5fc7206e252cf
These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
--HG--
extra : rebase_source : f142e3dbba0d70effe129dad43f139e494070d82
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
This keeps the banner text in sync with the doorhanger text.
MozReview-Commit-ID: Hwm3fvLZUHR
--HG--
extra : rebase_source : f115b493e8df4b8dc8c8f29f14de98a4c1d60c94
It's ok to cache the padding size of the main view and re-use it in this case,
because the padding is maintained for each view consistently.
The performance characteristics are therefore maintained.
MozReview-Commit-ID: GYT59NIiBET
--HG--
extra : rebase_source : 5bf7962367f1ff48f4e61a20535a4fbda82f419e
This Photon-specific workaround styles the zoom and edit
button combinations when the user switches back to the
old menu panel. Before this patch, it used to apply the
panel style even if the buttons were in the toolbar.
This patch fixes that by not even updating the style if
the buttons are not in the panel.
MozReview-Commit-ID: JZZUTudSDeZ
--HG--
extra : rebase_source : 6ea20aba09bfe12a558dc20a6e65f324292ca0f2
This also improves the styling of checkbox buttons inside the menu and improves
support for adopting panelviews into the app menu from another area properly.
MozReview-Commit-ID: 1I9CeBx3zrz
--HG--
extra : rebase_source : 2db487c3e8fb56bca20f8bf51367b724c677b10f
Right now notifications displayed in non-focused windows are causing that window to be focused. This is annoying. We could work to make the doorhangers not focus the other windows, but a simpler solution is to just not show the doorhanger until the window is focused. This has the added benefit of ensuring that the doorhangers entry animation is seen by the user, increasing the likelihood that they will notice it.
Additionally, some existing tests involving extra windows were refactored. I stripped the old tests of their extra windows and created new tests specifically to test the behavior of background windows. These tests were modeled off of the background window tests of PopupNotifications.jsm, which create a new window knowing that this will cause the existing window to be the background, rather than explicitly manipulating the focus of the two windows.
This also disables the menu button and overflow button correctly in
customize mode, and fixes an issues where the overflow button state
would stay 'open' when closing the panel by clicking the button
a second time.
MozReview-Commit-ID: BNTkE6zvv9Q
--HG--
extra : rebase_source : caa6ca5376c0b0e6c5d3190ffaed0b34e5292fb4
This reuses the logic we have for toolbar dragging and uses it for the photon panel (ie overflow panel)
to do vertical space-making animations.
It explicitly doesn't address the styling or permanently showing the overflow button (for which we have other bugs on file).
MozReview-Commit-ID: 4qrWC0H30xi
--HG--
extra : rebase_source : 57c413620aff496069b8cf371b8980a1fa432d72
extra : histedit_source : 60f65f3cb81ba0c64553bdac4dc502a6a704be90
This is unfortunate, but in order to keep automated tests working when we flip the pref,
it would be nice to be able to flip the pref at runtime and have things Just Work. This
tries to make that happen. We can remove most of this code post-Photon.
MozReview-Commit-ID: 8zbgCGJautO
--HG--
extra : rebase_source : 2b6df54d24d35294cc547be0b7abe5396ddec6b6
extra : histedit_source : a9b4654bbddc10a933f83a08f34d809a58b80ad9
Right now notifications displayed in non-focused windows are
causing that window to be focused. This is annoying. We could work
to make the doorhangers not focus the other windows, but a simpler
solution is to just not show the doorhanger until the window is
focused. This has the added benefit of ensuring that the doorhangers
entry animation is seen by the user, increasing the likelihood that
they will notice it.
Additionally, some existing tests involving extra windows were
refactored. I stripped the old tests of their extra windows and
created new tests specifically to test the behavior of background
windows. These tests were modeled off of the background window
tests of PopupNotifications.jsm, which create a new window knowing
that this will cause the existing window to be the background,
rather than explicitly manipulating the focus of the two windows.
MozReview-Commit-ID: 1fjrDOhEKCw
--HG--
extra : rebase_source : 954ace7e43da90fcee3da2d70c4bdbcda8456d77
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 : 4609fbc2d0bd38fe16a23151d94d265761cd57b0
