Make Places views constructors arguments more coherent, passing the root
and view elements up to the super class explicitly.
Remove the options argument, that was not strictly necessary, the same info can
be obtained directly.
Rename the "builder" attribute to "afterplacescontent" to clarify what it is
and make panel use it, instead of passing an insertionPoint option.
Additional cleanups:
Make chevron and BMB menus use coherent popupshowing observers.
Remove useless .viewElt accessor, .associatedElement can be used instead.
Avoid an access to the private _rootElt property from the controller.
Differential Revision: https://phabricator.services.mozilla.com/D164827
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
An all-device "Allow" option is not provided because the permission grant
prompt is primarily a device selection, which will (with subsequent patches)
grant persistent permission for the selected device.
Bug 1800287 covers setting a similar block from the selectAudioOutput() prompt.
Differential Revision: https://phabricator.services.mozilla.com/D162232
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
We need one more panel in the doorhanger- one that is a user information panel per (rp, idp, account) tuple.
This just gives the privacy policy and ToS links to the user. It is implemented similarly to the other panels,
and would similarly be updated by Bug 1800695.
Similar to the original doorhanger patch (Bug 1782088 - Create account chooser doorhanger for IdentityCredential)
tests and fine polish are out of scope for this prototype.
Differential Revision: https://phabricator.services.mozilla.com/D162126
Changed the aria role from tab to button to fix the VO announcement so that it correctly reports when the Fx View tab is actually selected.
Differential Revision: https://phabricator.services.mozilla.com/D159887
Modern flexbox increased the macOS compact mode toolbar height by 2px due to a line-height rule from bug 1402368. The issue from that bug no longer reproduces on current Nightly, even without the added rule, so it seems safe to remove.
There was also some extra spacing introduced with Proton that should have been only applied to the search "go" button, so I scoped that more tightly and also fixed the alignment of that button while at it.
Differential Revision: https://phabricator.services.mozilla.com/D159975
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Depends on D160292
Differential Revision: https://phabricator.services.mozilla.com/D160293
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Differential Revision: https://phabricator.services.mozilla.com/D160293
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Differential Revision: https://phabricator.services.mozilla.com/D160293
By using delegatesanchor="true", we delegate the anchor node to the
first in-flow box (that is the icon), simplifying a lot of the
hard-coded margins in the CSS.
Do that, plus make menupopup[type="arrow"] work consistently, to
simplify the styling of the bookmarks popup a bit.
Differential Revision: https://phabricator.services.mozilla.com/D158569
This simplifies the widget tracker code to avoid having to remove random
width attributes in all children.
Resize only the searchbar, since that's the only thing that's
effectively restored already on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D159071
This patch also adjusts some `min-width` rules like it was done for the
downloads button. It should work with either buttons OR both, which is
going to happen since the unified extensions button will be most likely
always visible in the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D154360
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This isn't needed anymore so that should make it more obvious that we
have a button only, outside the customization area because we don't want
it to be removed at the moment. That's also why the `overflows`
attribute has been added (the button should not go to the overflow on
window resize).
Differential Revision: https://phabricator.services.mozilla.com/D154089
