Now location objects are slightly different between SourceMapLoader and Debugger frontend.
SourceMapLoader doesn't make any use of the source objects, so I only pass `sourceId`.
This will reduce the amount of data transferred between the main thread and source-map worker.
But this requires mapping location objects in and out of the source map worker.
We were already mapping location objects returned by the worker in order to lookup
for the related source object.
Also make SourceMapLoader return null when the location doesn't map,
so that it is easier to identify when it doesn't map and prevent having to do:
`originalLocation.sourceId == location.sourceId`.
Differential Revision: https://phabricator.services.mozilla.com/D178397
Now location objects are slightly different between SourceMapLoader and Debugger frontend.
SourceMapLoader doesn't make any use of the source objects, so I only pass `sourceId`.
This will reduce the amount of data transferred between the main thread and source-map worker.
But this requires mapping location objects in and out of the source map worker.
We were already mapping location objects returned by the worker in order to lookup
for the related source object.
Also make SourceMapLoader return null when the location doesn't map,
so that it is easier to identify when it doesn't map and prevent having to do:
`originalLocation.sourceId == location.sourceId`.
Differential Revision: https://phabricator.services.mozilla.com/D178397
When inserting multiple URIs in history, it makes sense to delay expensive
frecency calculations to a later time. We only set recalc_frecency and the
PlacesFrecencyRecalculator will take care of it.
We keep immediately calculating frecency only when a single url is inserted,
that is the case when the user is normally browsing the Web.
Differential Revision: https://phabricator.services.mozilla.com/D179263
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
A unified extension item has two buttons: an action button and a menu
button. They are visually separated by 8px. The description string in
the action button depends on which of the buttons is hovered - the
action button, the menu button, or neither. If the mouse moves from the
action button to the menu button, it has to cross the 8px gap where
neither is hovered, causing the description to flash quickly between 3
strings. This patch circumvents that issue by making the 8px gap an
invisible padding of the menu button. This also removes the inert area
where you can move the mouse within the item and see a tooltip with the
name of the extension, but clicking would have no effect since a button
is not hovered.
Differential Revision: https://phabricator.services.mozilla.com/D177979
This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Differential Revision: https://phabricator.services.mozilla.com/D176811
This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Differential Revision: https://phabricator.services.mozilla.com/D176811
This patch has no observable changes, other than printing deprecation
messages when browser_style is effectively true in MV3.
This patch does include the full logic for all stages of the deprecation
process behind prefs, which will follow the schedule described at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1827910#c1.
All combinations of these prefs are fully covered by unit tests in
toolkit/components/extensions/test/xpcshell/test_ext_browser_style_deprecation.js
The next test tasks confirm the behavior of the current patch:
- browser_style_never_deprecated_in_MV2
- supported_with_browser_style_false
- supported_with_browser_style_true
- supported_with_mv2_defaults
Differential Revision: https://phabricator.services.mozilla.com/D176811
This removes `UrlbarProvider.pickResult()` and `blockResult()` in favor of
handling picks and dismissals through `onEngagement()`. A number of providers
use those two methods, so this revision touches a lot of files.
Handling dismissals through `onEngagement()` means `UrlbarInput.pickResult()`
can no longer tell whether a result is successfully dismissed, so it can't
remove the result anymore. (Maybe `onEngagement()` could return some value
indicating it dismissed the result, but I don't want to go down that road.)
Instead, I split `UrlbarController.handleDeleteEntry()` into two methods: a
public one that removes the result and notifies listeners, and a private one
that handles dismissing the selected result internally in
UrlbarController. Providers that have dismissable results should now implement
`onEngagement()` and call `controller.removeResult()`.
I made some other improvements to engagement handling. There's still room for
more but this patch is big enough already.
Other notable changes:
Include the engaged result in engagement notifications so providers have easy
access to it and can respond to clicks and dismissals more easily. That also
lets us stop passing `selIndex` and `provider` to `engagementEvent.record()`
since now it can compute those from the passed-in result.
Add the concept of `isSessionOngoing` to engagement notifications so providers
can tell whether an engagement ended the search session. Right now, providers
like quick suggest that record a bunch of provider-specific legacy telemetry
assume that `onEngagement()` ends the session, but that's no longer true.
Unify result buttons and result menu commands by setting
`element.dataset.command` on buttons (hopefully we can remove buttons soon, at
least the ones that aren't tip buttons)
Make sure we always notify providers on engagement even on dismissals or
when skipping legacy telemetry
Move dismissal of restyled search suggestions and history results from
`UrlbarController.handleDeleteEntry()` to the Places provider
Move dismissal of form history results from
`UrlbarController.handleDeleteEntry()` to the search suggestions provider
In the Places provider, remove the unused `_addSearchEngineMatch()` method. Also
remove the code in the "searchengine" case that creates a non-search-history
result. This code is unreached because the only time the provider creates a
"searchengine" match it also sets `isSearchHistory` to true.
In `UrlbarTestUtils.promiseAutocompleteResultPopup()`, change the default value
of the `fireInputEvent` param from false to true. This is necessary because
without a starting input event, the start event info in `engagementEvent` will
be null, so when `engagementEvent.record()` is called at the end of the
engagement, it will bail, and providers will not be notified of the engagement.
IMO true is a better default value anyway because input events will typically be
fired when the user performs a search.
Differential Revision: https://phabricator.services.mozilla.com/D174941
It looks like `extension.iconURL` never worked. I added a `getPreferredIcon()`
that relies on `IconDetails.getPreferredIcon()` under the hood in order to
easily get icon URLs from an instance of an `Extension`. I updated a few places
where using this new method is a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D173158
I wasn't able to hit this locally even when running the test with --verify, and in the failure logs from the
failures linked to orangefactor I couldn't find any that would provide me some clue of what is going on,
but if the identity box is being updates asynchronously then I would not exclude this may be hit only in
some cases that are never hit locally by executing this test file on its own.
This patch adds a few small changes to explicitly wait for a mutation of the identity box before asserting
the styles, the test was still passing consistently locally and so if this version would fail for
a timeout due to get stuck waiting for the mutation, then we would at least determine that the identity
box would very likely never be updated and there may be something else going on that may be worth digging
further into.
Differential Revision: https://phabricator.services.mozilla.com/D171497
This is a test-only change. It introduces a new Urlbar pref to make the
existing 3000 ms timeout configurable.
That timeout is currently reached 8 times in the test. That means that
the test will take at least 3 x 8 = 24 seconds to run while basically
doing nothing, and makes the test prone to reach the deadline by which
the test is declared timed-out.
To avoid "Test timed out" errors, the test now reduces the fixed 3000 ms
timeout to 500 ms, so now we wait for 8x500 = 4 seconds instead of 24.
Differential Revision: https://phabricator.services.mozilla.com/D169846
