This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
* For cases where a user does not have automatic session restore enabled, recently closed
tabs will persist between sessions and previously open tabs will be added to the recently closed tabs
list; upon manual session restore, the previously open tabs will reopen and be removed from the closed tabs list
* Add marionette test and fix test bustages due to these changes.
Differential Revision: https://phabricator.services.mozilla.com/D178521
* 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
* This patch expands this keyboard shortcut to support whichever of the three
last actions were taken - last tab closed, last window closed or session restore.
* Existing test file was renamed and additional cases added.
Differential Revision: https://phabricator.services.mozilla.com/D178965
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
Just forgetting to map them to new `key_enterFullScreen`. Note that both
`key_enterFullScreen` and `key_exitFullScreen` have same shortcut keys.
Therefore, mapping only to `key_enterFullScreen` must be fine for the
toggle UIs.
This patch does not contain the tests for checking the tooltip label on
the toolbar buttons because the shortcut key information does not appear
in the DOM tree.
Differential Revision: https://phabricator.services.mozilla.com/D179357
This adds the translations panel to the app menu, per UX's
recommendation. The menu is hidden by default until the translations
pref is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D179088
The Fluent migration will show a diff for two en-US messages:
- `popup-warning-message` singular variant does not include `{ $popupCount }`, so is more appropriately using `1` rather than `one` as its key.
- `popup-warning-exceeded-message` has only one variant in English, but using the plural selector forces its use for new locales.
Differential Revision: https://phabricator.services.mozilla.com/D177666
The PIN for a user's security key will be temporarily blocked after three
failed PIN entry attempts, but the "retries left" counter in the invalid PIN
prompt is the (typically larger) number of attempts left before the PIN is
permanently blocked. This patch makes it so that the retries left counter is
only shown when it is equal to 1, 2, or 3.
Differential Revision: https://phabricator.services.mozilla.com/D177294
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
Experimentation confirmed years ago that about:welcome shoudln't be treated as blank for urlbar focus, and no need for additional experimentation. Also fix a bug where about:welcome was treated as a blank/empty page resulting in about:preferences incorrectly replacing it.
Differential Revision: https://phabricator.services.mozilla.com/D174940
This code is untested since it's stubbing out functionality, which will
eventually use PageActions to open up a popup. The final code with the
popup will get tested, but for now rely on the existing test behavior,
without asserting new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D173196
This code is untested since it's stubbing out functionality, which will
eventually use PageActions to open up a popup. The final code with the
popup will get tested, but for now rely on the existing test behavior,
without asserting new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D173196
I'm removing the apptab bits completely in one of the later commits,
but trying to keep this modular so it's easy to figure out regressions,
should there be any.
Differential Revision: https://phabricator.services.mozilla.com/D171411
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
In the past screenX etc didn't return CSS pixels properly, but now they
do and have for a while. Also the full zoom value of browser.xhtml is
always one, so this is only broken if we have OS text scale.
Depends on D170195
Differential Revision: https://phabricator.services.mozilla.com/D170196
This moves the somewhat out-of-place `_loadURI` method and its dependencies
into tabbrowser, and deals with receiving either a string or a URI.
Depends on D168391
Differential Revision: https://phabricator.services.mozilla.com/D168392
This moves the somewhat out-of-place `_loadURI` method and its dependencies
into tabbrowser, and deals with receiving either a string or a URI.
Depends on D168391
Differential Revision: https://phabricator.services.mozilla.com/D168392
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
Ensure that we can safely load `editBookmark.js` as the `gEditItemOverlay` instance without breaking the library panel. As the library does not currently support OK/Cancel operation, this does not perform any "delayed apply" logic, we simply save on blur as usual.
The tricky part was getting bulk tagging to work. With the current design of the `BookmarkState` class, it only supports modifying a **single** bookmark, and it will break when trying to add a tag to multiple bookmarks at once. This is where we left off with the previous revision... I believe in this case, it makes sense to simply revert back to the logic we had in `instantEditBookmark.js` to perform the bulk tag operation.
https://treeherder.mozilla.org/jobs?repo=try&revision=a1f58a770b16edd519da6e0d55e2f3c529d8f8de
Differential Revision: https://phabricator.services.mozilla.com/D164250
