* Change the signature for SessionStore.getClosedTabCount to accept either a window or options object
* Extend tests for the recently-closed-tabs menu(s)
* Add a test manifest to run the session/recently-closed tabs related extension tests with the
legacy (false) values for the all-windows and closed tabs from closed windows prefs
Differential Revision: https://phabricator.services.mozilla.com/D186400
* Menu Bar History menu recently-closed tab items includes closed tabs from all currently-open windows
* Toolbar/Appmenu history menu recently-closed tabs list includes closed tabs from all currently-open windows
* Firefox view recently-closed tab list includes closed tabs from all currently-open windows
* All recently-closed tab menu/items re-open in the current window
* Re-open all tabs menu item re-opens all tabs into the current window
* Ensure we filter out tabs without any useful state in firefox-view
* Add a target window argument to undoCloseTab and undoCloseById
* undoCloseTab will remove the tab data from the source window collection and re-open the tab into the target window
* Add an options argument to SessionStore.getWindows to get all private or non-private windows
* Add a getWindowForTabClosedId method on SessionStore, allowing look-up of the window associated with a closed tab
* Ensure recently-closed tab lists only include tabs from non-private windows when attached (i.e. opened from) a non-private window. And vice-versa.
* Update the sessionstore closed tab tests to assert on the new behavior
* Update the browser.sessions.restore implementation to always find and pass the source window when restoring a closed tab
* sessions.restore should always restore closed tabs to the source window as there's no implicit top or current window in the API context
Differential Revision: https://phabricator.services.mozilla.com/D174501
* Menu Bar History menu recently-closed tab items includes closed tabs from all currently-open windows
* Toolbar/Appmenu history menu recently-closed tabs list includes closed tabs from all currently-open windows
* Firefox view recently-closed tab list includes closed tabs from all currently-open windows
* All recently-closed tab menu/items re-open in the current window
* Re-open all tabs menu item re-opens all tabs into the current window
* Ensure we filter out tabs without any useful state in firefox-view
* Add a target window argument to undoCloseTab and undoCloseById
* undoCloseTab will remove the tab data from the source window collection and re-open the tab into the target window
* Add an options argument to SessionStore.getWindows to get all private or non-private windows
* Add a getWindowForTabClosedId method on SessionStore, allowing look-up of the window associated with a closed tab
* Ensure recently-closed tab lists only include tabs from non-private windows when attached (i.e. opened from) a non-private window. And vice-versa.
* Update the sessionstore closed tab tests to assert on the new behavior
* Update the browser.sessions.restore implementation to always find and pass the source window when restoring a closed tab
* sessions.restore should always restore closed tabs to the source window as there's no implicit top or current window in the API context
Differential Revision: https://phabricator.services.mozilla.com/D174501
- 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
