- 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
The five strings used by the component are collected into one new file.
The dropped `menuUndoCloseWindowSingleTabLabel` is the same in all locales,
so it was easier to recreate its contents in the custom Fluent migration transform.
Differential Revision: https://phabricator.services.mozilla.com/D177614
Remove the `browser.bookmarks.editDialog.delayedApply.enabled` pref, and for all usages in conditional branches, assume that it is `true`. (Since we want to be using delayed apply logic going forward.)
`delayed_apply` spinoffs of tests are removed and merged with their instant apply counterparts. The only test removed without a corresponding spinoff is `browser_editBookmark_tags_liveUpdate.js`. That test is checking whether tags are updated in the edit dialog, if they are updated from a different place. The problem is that we don't really want this behavior anymore. It was previously set to only run with `browser.bookmarks.editDialog.delayedApply.enabled` set to `false`, but now that it's no longer configurable, it made most sense to simply get rid of this test.
https://treeherder.mozilla.org/jobs?revision=c0741eca62212a75a9dd52fc2c5c2b6c34f9f2d7&repo=try
Differential Revision: https://phabricator.services.mozilla.com/D176370
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
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
Unfortunately lazy script getters load the file once for each accessed symbol, which
redeclares "let" and "const" and "class" variables, which was a problem here. But also,
loading the file multiple times is bad for performance (it is not a module so we
actually reload it) and the "lazy" variables get dereferenced immediately from
markup that is present both in browser.xhtml and the hidden window on macOS, so I
doubt lazy loading was getting us anything performance-wise.
This patch simplifies things by 'just' loading the file from the markup.
Differential Revision: https://phabricator.services.mozilla.com/D163934
It was rather complicated because we want the import button to behave
as a bookmark item when in there, but as a regular icon otherwise.
We can achieve that more simply by actually toggling its styling. This
allows us to have less special-cases in toolbarbuttons.css
Differential Revision: https://phabricator.services.mozilla.com/D160045
Long ago, the menu panel in was a customizable area that users could drag things into.
That changed back around 2017 in bug 1354117 when the Photon redesign was built. The
menu panel become a static menu, but we also made it possible to permanently move things
to the overflow panel of the nav-bar.
It looks like we never updated the area type constant from referring to the old menu panel
though, so it's "TYPE_MENU_PANEL", and registering a node for it happens with
registerMenuPanel. This patch changes to constant to TYPE_PANEL and updates the registration
method to registerPanelNode.
I a check around the codebase as well as GitHub looking to see if there were any
system add-ons or experimental WebExtensions that rely on TYPE_MENU_PANEL / registerMenuPanel,
but I couldn't find any.
Differential Revision: https://phabricator.services.mozilla.com/D161078
I have fixed the underlying XPConnect issue, so these workarounds should
no longer be needed.
There are also two more in browser/base/content/browser-siteProtections.js
that I have not fixed.
Differential Revision: https://phabricator.services.mozilla.com/D158158
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
