When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode.
The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.)
Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190
However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method.
Other things I tried or thought of doing:
Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.)
Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!)
Differential Revision: https://phabricator.services.mozilla.com/D29613
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
So it is still preventDefault()able once non-primary clicks aren't web visible.
Don't let browser.js' contentAreaClick handle any non-primary clicks.
ClickHandlerChild.jsm handles them first anyway. Can probably rip it out
entirely in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D26791
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
Applying the attribute early enough allows us to avoid rebinding the urlbar,
plus a few checks to ensure "popup" windows, without a visible toolbar, work
properly.
Differential Revision: https://phabricator.services.mozilla.com/D27253
--HG--
extra : moz-landing-system : lando
Removed FX_PREFERENCES_OPENED_VIA probe as it expired in 63.Origin parameter for openPreferences has also been removed.
Differential Revision: https://phabricator.services.mozilla.com/D26795
--HG--
extra : moz-landing-system : lando
The larger changesets in this patch are simply moving code from one file into the other with hg mv.
A short summary of the changes:
- I removed the forked redirection from AboutRedirector.cpp
- I deleted the original aboutNetError.xhtml and aboutNetError.css files
and moved aboutNetError-new.xhtml and aboutNetError-new.css in their place instead.
- I removed the browser.security.newcerterrorpage.enabled pref and all its usages.
- I removed some localization strings and resources that went unused because of the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D25232
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
Add histograms to count fingerprinting and cryptomining blocking states per page load.
Differential Revision: https://phabricator.services.mozilla.com/D20389
--HG--
extra : moz-landing-system : lando
This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
When switching tabs we use the securityUI.contentBlockingEvent property to update the shield state.
That property is set in https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/browser.js#5025.
Unfortunately, that event is only received by the current browser because is is registered with gBrowser.addProgressListener instead of gBrowser.addTabsProgressListener. Thus, the background tab is not storing its content blocking event.
To fix this, we also listen for content blocking events with addTabsProgressListener, but exclude the
currently selected tab there.
Differential Revision: https://phabricator.services.mozilla.com/D23485
--HG--
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
Add histograms to count fingerprinting and cryptomining blocking states per page load.
Differential Revision: https://phabricator.services.mozilla.com/D20389
--HG--
extra : moz-landing-system : lando
This also changes the name of 'canceledAuthenticationPromptCounter' to account for the
fact that we no longer count up when the prompt was cancelled, but when it was shown.
Differential Revision: https://phabricator.services.mozilla.com/D21680
--HG--
extra : moz-landing-system : lando
We had previously missed to call browser.updateSecurityUIForContentBlockingEvent on
onLocationChange updates, to reset the contentBlockingEvent state. This would mean that
on tab switch the contentBlockingEvent state for benign pages would still be what it was
set to on the last tracker page.
Differential Revision: https://phabricator.services.mozilla.com/D20328
--HG--
extra : moz-landing-system : lando
This patch changes the name of LanguagePrompt.jsm to RFPHelper.jsm.
The RFPHelper is going to not only be responsible for the language
--HG--
rename : toolkit/components/resistfingerprinting/LanguagePrompt.jsm => toolkit/components/resistfingerprinting/RFPHelper.jsm
extra : histedit_source : 37b437de2c52b37b07da11cabdbcb9f2749c0a65
This patch changes the name of LanguagePrompt.jsm to RFPHelper.jsm.
The RFPHelper is going to not only be responsible for the language
--HG--
rename : toolkit/components/resistfingerprinting/LanguagePrompt.jsm => toolkit/components/resistfingerprinting/RFPHelper.jsm
extra : rebase_source : 58e6b8e167dfb01db9115a9b8c929fe533e31592
Replaced new Function() by CustomEvent carrying original click event as sourceEvent.
Adapted all oncommand listeners to use event.sourceEvent instead of event.
Differential Revision: https://phabricator.services.mozilla.com/D18847
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
The fix in bug 1312243 introduced a maximum of three consecutive cancelations (controlled by a pref) that a user could perform until Firefox would prevent the page from showing more dialogs.
This, in my opinion, is a great idea. The implementation, however, has a major fallacy: It checks the inner window id in the well-meaning attempt to find user navigation or reloads and clears its internal counter when that window id changes. Unfortunately this also clears the counter on non-user-initiated navigations and reloads. I believe that the true intention of the patch was to cancel the auth dialog after 3 attempts, except if:
- The user reloads the page on their own terms
- The user navigates to a different site on their own
Which is what I plan to implement, using the same pattern we applied to implement temporarily blocked site permissions:
- Temporarily store basic auth counter state on the browser object, as a map from baseDomain (eTLD+1) to number of cancellations
- Reset this state only on user initiated reload
- Reset the counter for a domain if the user has entered login data into the dialog and submitted
This would mitigate the DOS issue while hopefully not breaking any sites that rely on basic auth.
Differential Revision: https://phabricator.services.mozilla.com/D18019
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : 1505cf27f900070debc1f9e1c71ec4bef3bc099d
extra : source : 05200c5388b4f7adc4414268727458515d7b9ed9
On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : a033baf831aa8b9fcfa95d1f921364632a837390
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This includes a new test for the feature and a bit of test cleanup to factor
out all exception related tests into their own test file.
Differential Revision: https://phabricator.services.mozilla.com/D17109
--HG--
rename : browser/base/content/test/about/browser_aboutCertError.js => browser/base/content/test/about/browser_aboutCertError_exception.js
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
We can just add `onLinkIconAvailable` to `TabsProgressListener` in browser.js and update the search badge.
Differential Revision: https://phabricator.services.mozilla.com/D16590
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
Instead of opening the pop-up permissions dialog with the origin already populated, this command now highlights the pop-up permission row in the preferences. This doesn't remove any functionality because the only action that would be available for the origin in the permissions dialog is "Allow", which is equivalent to the "Allow pop-ups for" command in the notification bar menu.
Differential Revision: https://phabricator.services.mozilla.com/D15066
--HG--
extra : rebase_source : 064b3d39dc2a8c4d6a3c0949a51ab361ed6e71dd
When focused, the Back and Forward buttons previously couldn't be activated by pressing space or enter.
Although they do have a command event handler, they have type="menu", which means the command event is not fired for key presses by default.
Since these buttons are special (in that they have type="menu" and a command event), this change implements specific keyboard behavior for these buttons.
Differential Revision: https://phabricator.services.mozilla.com/D12868
--HG--
extra : moz-landing-system : lando
This also makes it so that the initial browser tab setup code can handle a JS array
as the URI(s) to load during start-up. If it's an array, the first element of that
array is inspected to determine what process type the initial browser tab should
be in.
Differential Revision: https://phabricator.services.mozilla.com/D14755
--HG--
extra : moz-landing-system : lando
For a better user experience of auto-blocking canvas extraction, this
patch changes the behavior when detecting a canvas extraction without
user interaction. It will show a canvas identity block icon with a
hidden doorhanger when auto-blocking the canvas extraction. Users can
make their choice to either block or allow the canvas extraction by
clicking the identity block icon and then refresh the page to make
the canvas permission taking effect.
Differential Revision: https://phabricator.services.mozilla.com/D14259
--HG--
extra : moz-landing-system : lando
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
The APNG version is still used by the TabsList which can't support the SVG version of the throbber currently.
Differential Revision: https://phabricator.services.mozilla.com/D13461
--HG--
extra : moz-landing-system : lando
We should be ignoring about: URIs for the page load time metric, since they load very quickly
and aren't representative of Web page load times.
Differential Revision: https://phabricator.services.mozilla.com/D12492
--HG--
extra : moz-landing-system : lando
The FX_PAGE_LOAD_MS histogram, implemented in Bug 790213, measures the time it takes
Firefox to load a page's static content. Unfortunately, it uses only 20 buckets to cover
a 10,000ms range, so resolution is quite poor. The modal bucket is 860ms wide. There is
at least anecdotal evidence that increasing page load times by increments as small as 100 ms
can alter user behavior, so much better resolution is required to have confidence in changes
we expect to alter page load times. Also fixes Bug 1364957.
Differential Revision: https://phabricator.services.mozilla.com/D11198
--HG--
extra : moz-landing-system : lando
As part of the conversion, support for notificationsHidden and children that are not notifications is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D10894
--HG--
rename : toolkit/content/widgets/notification.xml => toolkit/content/widgets/notificationbox.js
extra : rebase_source : 36a5412e1e9a9dc591fd486d1123c1f763a6f173
This also removes testing for the unused PRIORITY_CRITICAL_BLOCK behavior, and simplifies how Print Preview hides the chrome while removing leftover code.
The only theme-specific mochitest that ever existed checked an overflow scenario that is no longer relevant, so the test and its build folder are removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D10578
--HG--
extra : rebase_source : 93276d403b85dea6bce3b678100328eb66486eaa
extra : source : aaf1a7164c5b4f75882be574edc92fd69e906129
* If a search is performed in a private window and the new pref `browser.engagement.search_counts.pbm` is true, then do not record `SEARCH_COUNTS` telemetry. Note that the the pref must be true. If it's false or doesn't exist, then we record telemetry even in pbm like we normally do currently. (We record `SEARCH_COUNTS` telemetry in two places: (1) In BrowserUsageTelemetry.jsm, and (2) "in-content" telemetry directly in the search service. So skip both of those places.)
* Also skip the other ancillary telemetry recorded by `BrowserUsageTelemetry._recordSearch`: a keyed scalar and a telemetry event.
* I made some modifications to the search service to let me test the "in-content" telemetry keys
Differential Revision: https://phabricator.services.mozilla.com/D10851
--HG--
extra : moz-landing-system : lando
nsIBrowserSearchService::currentEngine and nsIBrowserSearchService::defaultEngine are the same thing.
The use of defaultEngine makes more sense and thus we are phasing out the use of currentEngine and replace it with defaultEngine.
Differential Revision: https://phabricator.services.mozilla.com/D7972
--HG--
extra : moz-landing-system : lando
Support for finding text in a page is now determined by a blacklist of locations, simplifying handling in multi-process mode and restoring the intended behavior.
Differential Revision: https://phabricator.services.mozilla.com/D8005
--HG--
extra : rebase_source : 129f3d4e3cdd3673251ed7a3cc58101dd3cb0c91
I left off the part about adding Reload Tabs to the All Tabs menu since the specs don't mention how this would appear with the New Container Tab menuitem and the Tab Manager project has been split off from the multiselect tabs project.
Differential Revision: https://phabricator.services.mozilla.com/D8274
--HG--
extra : moz-landing-system : lando
In order to improve the window rounding fingerprinting protection, we
want to find a proper rounding value which provides good protection as
well as good user experience.
With a better understanding of the content window size, we can answer
the question that which strategy we should use for improving this
protection: should we use certain fixed window sizes or still
stick with the current rounding strategy? Also, if we still stick with
the current approach, then what is the best rounding value which allows
users to utilize their window as much as possible without losing too
much protection.
Differential Revision: https://phabricator.services.mozilla.com/D7236
--HG--
extra : moz-landing-system : lando
nsIBrowserSearchService::currentEngine and nsIBrowserSearchService::defaultEngine are the same thing.
The use of defaultEngine makes more sense and thus we are phasing out the use of currentEngine and replace it with defaultEngine.
Differential Revision: https://phabricator.services.mozilla.com/D7972
--HG--
extra : moz-landing-system : lando
I changed the toolbar context menuitem from 'Bookmark All Tabs' to 'Bookmark Selected Tabs' because it is separated from a specific tab and thus it is not clear which tab would get bookmarked if only one is selected. This seemed much clearer to me in my testing. The wording of 'Bookmark Selected Tabs' is already used elsewhere where we have 'Reload Selected Tabs', 'Close Selected Tabs', etc.
Differential Revision: https://phabricator.services.mozilla.com/D7217
--HG--
extra : moz-landing-system : lando
I changed the toolbar context menuitem from 'Bookmark All Tabs' to 'Bookmark Selected Tabs' because it is separated from a specific tab and thus it is not clear which tab would get bookmarked if only one is selected. This seemed much clearer to me in my testing. The wording of 'Bookmark Selected Tabs' is already used elsewhere where we have 'Reload Selected Tabs', 'Close Selected Tabs', etc.
Differential Revision: https://phabricator.services.mozilla.com/D7217
--HG--
extra : moz-landing-system : lando
