The `PanelMultiView.showSubView()` method needed to be made a bit more robust
for titles set by DOM localization rather than directly.
The following messages are dropped during the migration, as they are unused:
- contentBlocking.trackersView.blocked.label
- contentBlocking.cookiesView.firstParty.empty.label
- contentBlocking.cookiesView.trackers.empty.label
- contentBlocking.cookiesView.thirdParty.empty.label
- contentBlocking.fingerprintersView.blocked.label
- contentBlocking.cryptominersView.blocked.label
Differential Revision: https://phabricator.services.mozilla.com/D178829
Changing a panel for the sidebar menu popup to utilize PanelMultiView component that provides most of the panel's a11y out-of-the-box, as well as adding some additional properties to provide more information to AT.
Also adding a support to `keydown` event for the PanelMultiView focus management to backup the deprecated `keypress`.
Differential Revision: https://phabricator.services.mozilla.com/D178260
The `PanelMultiView.showSubView()` method needed to be made a bit more robust
for titles set by DOM localization rather than directly.
The following messages are dropped during the migration, as they are unused:
- contentBlocking.trackersView.blocked.label
- contentBlocking.cookiesView.firstParty.empty.label
- contentBlocking.cookiesView.trackers.empty.label
- contentBlocking.cookiesView.thirdParty.empty.label
- contentBlocking.fingerprintersView.blocked.label
- contentBlocking.cryptominersView.blocked.label
Differential Revision: https://phabricator.services.mozilla.com/D178829
This patch was generated as follows:
Run:
`./mach esmify --imports . --prefix=toolkit/mozapps/extensions/AddonManager`
In the output there are linter/prettifier errors due to unused
XPCOMUtils or separate importESModule calls. These have been fixed
manually and verified with `./mach lint --outgoing`.
The `esmify` script also inserts many unwanted newlines around imports
that are broken on two lines due to length. Due to the number of these,
I fixed them programatically.
1. Create patch from the changes so far.
2. From the patch, delete all lines that consist of "+" (i.e. added blank line).
3. Reset the working dir and apply the revised patch.
4. Verify that the diff between step 1 and 3 looks reasonable.
5. Verify that this patch as a whole looks reasonable.
Commands:
```
git diff > rename.diff
:%g/^+$/d
git commit -va -m WIP-rename
git revert HEAD
git apply --recount rename.diff
git diff HEAD^ # and verify that the removed lines are ok.
git commit -va # one last review to verify correctness of whole patch.
git rebase -i HEAD~3 # drop the WIP + reverted commit, pick only the last.
```
`git apply` has the `--recount` option to force it to ignore mismatches
in line counts, which happens because we deleted added lines (^+$)
without fixing up the line counts in the file headers.
Differential Revision: https://phabricator.services.mozilla.com/D179874
- As closed tabs will change to mean closed tabs from all windows, rename these functions to make
changes in later patches clearer when we mean closed tabs from this window specifically, or closed
tabs for all private/non-private windows
Differential Revision: https://phabricator.services.mozilla.com/D177849
Changing a panel for the sidebar menu popup to utilize PanelMultiView component that provides most of the panel's a11y out-of-the-box, as well as adding some additional properties to provide more information to AT.
Also adding a support to `keydown` event for the PanelMultiView focus management to backup the deprecated `keypress`.
Differential Revision: https://phabricator.services.mozilla.com/D178260
Also remove public access to the internal Localization instance
and update the call in CustomizableWidgets to not detach the method.
Differential Revision: https://phabricator.services.mozilla.com/D178049
This does two things:
* Modify `nsXULPopupManager::ShowPopup()` so it calls `ShowPopupAsNativeMenu()`
as long as an anchor wasn't passed in, and only on Mac.
* Modify `-[MOZMenuOpeningCoordinator _openMenu:atScreenPosition:forView:withAppearance:]`
so it also takes a `aIsContextMenu` param. If the param is true, we synthesize
a right-click event and pop up a context menu as usual. If it's false, we use
`-[NSMenu popUpMenuPositioningItem:atLocation:inView:]` instead.
The reason this works is because `-[NSMenu popUpMenuPositioningItem:atLocation:inView:]`
opens the menu in a sensible place when the x-y coords are near the right edge
of the screen. In contrast, `+[NSMenu popUpContextMenu:withEvent:forView:]` will
anchor the menu's top-right corner to the mouse cursor when near the right edge.
Differential Revision: https://phabricator.services.mozilla.com/D177355
This is a quick fix to unblock some onging work to use moz-toggle in the chrome. I'll follow up by filing a bug to reevaluate focus management in PanelMultiView more generally.
Differential Revision: https://phabricator.services.mozilla.com/D176678
Since moz-support-link elements can be declared in markup or created
in JS, we needed to add a localName check to the
_makeNavigableTreeWalker function. This localName check allows the
moz-support-link, or any anchor element, to be tab navigable when
used within a <panelview> element.
Differential Revision: https://phabricator.services.mozilla.com/D174981
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Customize mode was already using display: flex, so the migration caused
some interesting interactions.
In particular -moz-box-flex: 1 rules had no effect at all, so remove
them (same for the flex="" attribute).
Un-flex items in the overflow menu so that they don't spread too much.
Use flex: 1 in the customization-content-container to reset flex-shrink
to 1 (XUL flex didn't allow shrinking by default, so xul.css has
flex-shrink: 0).
Differential Revision: https://phabricator.services.mozilla.com/D172144
While at it remove useless display declaration too.
vbox was setting -moz-box-orient: vertical, but that had no effect
because it had display: flex explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D172145
openLinkIn would really benefit from being split up a bit, and adding more
globals to the browser window is icky. Also, the story for opening new tabs if
you're not inside a window is a nightmare right now. Moving this code
to a module is a first step to making that story nicer.
I kept wrappers for all the functions I'm moving, and added the `window` as the
first argument. In the future we can update these functions to support being
called without a `window` ref. The one exception is getTopWin, where I updated
the callers in this patch.
I had to tweak the parameter detection of the different arguments supported by
openUILinkIn because forwarding calls means arguments.length is always larger
than 3... but then also removed it in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D170210
openLinkIn would really benefit from being split up a bit, and adding more
globals to the browser window is icky. Also, the story for opening new tabs if
you're not inside a window is a nightmare right now. Moving this code
to a module is a first step to making that story nicer.
I kept wrappers for all the functions I'm moving, and added the `window` as the
first argument. In the future we can update these functions to support being
called without a `window` ref. The one exception is getTopWin, where I updated
the callers in this patch.
I had to tweak the parameter detection of the different arguments supported by
openUILinkIn because forwarding calls means arguments.length is always larger
than 3... but then also removed it in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D170210
