It's default value is `true`.
`dom.keyboardevent.keypress.set_keycode_and_charcode_to_same_value` will neve
be reverted in release builds by default. Therefore, we can get rid of it
from the tests unless testing non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119851
Its default value is `true` and it will never be reverted in release builds
by default. Therefore, we can get rid of it from the tests unless testing
non-default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D119849
The original GA code returns an Array for ga.getAll(), while the
shim was returning an Iterator. This caused code that relied on
ga.getAll().filter(..) to break with the shim. This patch wraps
the Iterator contents back into an Array.
Differential Revision: https://phabricator.services.mozilla.com/D119737
`beforeinput` event was shipped and it won't be disabled for avoiding confusion
of web developers. So, we can drop the pref setting of
"dom.input_events.beforeinput.enabled" in our tests.
Depends on D119716
Differential Revision: https://phabricator.services.mozilla.com/D119729
See discussion in the last few comments on the bug. If we don't wait for the correct URL
to load in the browser, the SpecialPowers.spawn task can get aborted, which causes the
test to fail.
Differential Revision: https://phabricator.services.mozilla.com/D119518
Port Bug 1601256 to dialogs/permissions.js. Unfortunately these files forked even though they are very similar. This leads to bugs like this being introduced.
Differential Revision: https://phabricator.services.mozilla.com/D118888
Removing the following vars from common.inc.css
- `--in-content-button-border-radius`
- `--in-content-button-horizontal-padding`
- `--in-content-button-vertical-padding`
Differential Revision: https://phabricator.services.mozilla.com/D119190
Port Bug 1601256 to dialogs/permissions.js. Unfortunately these files forked even though they are very similar. This leads to bugs like this being introduced.
Differential Revision: https://phabricator.services.mozilla.com/D118888
The mozSubdialogReady was being set inside of sanitize.xhtml in
its load event handler, which would be scheduled to run AFTER the
SubDialog _onLoad handler (which is what awaits mozSubdialogReady).
The only reason this wasn't more obvious is because the first time
the dialog is opened, the SubDialog _onLoad handler awaits
translation of the document, which gives sanitize.xhtml a chance
to run its load event handler and set the mozSubdialogReady.
Subsequent opens of the dialog wouldn't need to re-run translation
due to document caching, and so the mozSubdialogReady wouldn't
be waited for, resulting in incorrect dialog layout.
Depends on D119329
Differential Revision: https://phabricator.services.mozilla.com/D119330
These handlers and markup were only ever relevant when opening the
dialog in an old-style modal. Now that we're opening the dialog as
a SubDialog, these conditions can be cleaned up.
Depends on D117567
Differential Revision: https://phabricator.services.mozilla.com/D119329
There's more I'd like to do here. Namely, I want to eliminate the Search class in favour of everything being part of ProviderPlaces, and I'd like to get rid of "match" objects/nsIAutoCompleteResult in favour of always dealing with UrlbarResults. I think major changes like those are best left to bug 1717511. The latter change would require moving the muxer-lite deduping code from ProviderPlaces to the muxer. That way, ProviderPlaces can just send results to the muxer as soon as they're ready rather than needing to first order them inside an nsIAutoCompleteResult.
Differential Revision: https://phabricator.services.mozilla.com/D119308
UnifiedComplete must stick around to serve as an mozIPlacesAutoComplete implementation for XUL consumers like search.js and privacy.js.
Differential Revision: https://phabricator.services.mozilla.com/D119306
Previously the WebProgressListener in AboutWelcomeChild was detecting
OnLocationChange notifications for loading about:welcome rather than
notifications for navigating away from it, meaning that
AWTerminate.UNKNOWN was almost immediately replaced as soon as the
document was loaded, rather than only when navigating away. The
DOMDocElementInserted event fires slightly later than DOMWindowCreated
so the actor no longer sees the OnLocationChange notification for the
current document, causing tests to fail.
As this telemetry is no longer actively monitored, this patch removes
AWTerminate.UNKNOWN to preserve the existing behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D118620
This fixes a regression from bug 1708882 by adjusting the position of the button contents rather than the entire button.
Differential Revision: https://phabricator.services.mozilla.com/D119198
Apologies in advance for this review. It's the test I've had to rewrite the most. This is because the unifiedcomplete tests did not care about sorting, and urlbar tests do. Since this test does some complicated stuff with frecency, many of the expected matches had to be reordered in the test. The old test just listed all the uris in descending order in `matches`, paying no mind to frecency. As I've been doing with other tests, I reversed the order which with they are added to history/bookmarks, to reduce the number of changes required in the sets of expected matches.
That yielded this order, in descending order of frecency:
uri11
uri1
uri4
uri6
uri5
uri7
uri8
uri9
uri10
uri12
uri2
uri3
Differential Revision: https://phabricator.services.mozilla.com/D119113
This bug was introduced because UnifiedComplete was only filtering tokens when the queryContext contained a restrictToken. UrlbarProvidersManager was only setting queryContext.restrictToken when a source restriction token was typed (i.e. not including $ and #). This meant that # and $ were never filtered from the search string. This patch now sets restrictToken to whatever the first token is, including # and $. This ensures UnifiedComplete will always filter tokens when a restriction token is typed.
Differential Revision: https://phabricator.services.mozilla.com/D119197
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
Package a summary of the RemoteSettings dumps with the application, so
that RemoteSettings clients can look up the last_modified value of a
dump without loading the whole JSON dump file.
For simplicity, the initial version of `gen_last_modified.py` generates
only one entry for the only present use case. A more generic version of
the script will be implemented in bug 1719560.
Differential Revision: https://phabricator.services.mozilla.com/D119336
Patch appends screen order in message id to be passed in Impression and Click telemetry from respective screen. This is useful to keep onboarding engagement dashboard consistent across releases by using message id that begins with 'feature id_screen order_%'
Differential Revision: https://phabricator.services.mozilla.com/D119345
- adds an actual shim for Google IMA3, rather than shimming with an empty file
- simplifies the AdSafeProtected IMA shim:
- no longer needs to opt in to the original script for videos to play
- it can now just be a basic stub shim for the API
Differential Revision: https://phabricator.services.mozilla.com/D119337
There are two substantive changes to test_protocol_swap worth pointing out:
1. Some subtests now search for <protocol>://sit instead of <protocol>://site. This is because the latter would make the heuristic result the same as the relevant history result and the history result would be deduped. We would thus lose test coverage for that history result.
2. Tests that expected allMatches no longer expect uri5. The muxer dedupes https://www. URLs in favour of https:// URLs.
Depends on D118636
Differential Revision: https://phabricator.services.mozilla.com/D118637
The last few subtests in test_tags_returnedInSearches.js got substantive changes. This is because urlbar tests reflect the results actually shown in the Urlbar and unifiedcomplete tests just tested what came out of UnifiedComplete. Those last few subtests tested that we show non-matching tags. While UnifiedComplete returns those non-matching tags, UrlbarProviderUnifiedComplete has filtered them out since bug 1522226.
Differential Revision: https://phabricator.services.mozilla.com/D118635
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
I was unable to reproduce this locally, but looking to the logs from the failures tracked by this bug
I did notice this logged error which suspiciously point in the direction of a race between registering
a browser.runtime.onMessage listener and sending a message to that listner from the content script "script.js":
```
Console message: [JavaScript Error: "Error: Could not establish connection. Receiving end does not exist."
{file: "moz-extension://f0d0d3ec-6815-4d78-aa83-3516814353a2/script.js" line: 2}]
```
This patch just change the order of those two promise, making sure that the browser.runtime.onMessage will be registered by the time the content script is going to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D119175
I was unable to reproduce this locally, but looking to the logs from the failures tracked by this bug
I did notice this logged error which suspiciously point in the direction of a race between registering
a browser.runtime.onMessage listener and sending a message to that listner from the content script "script.js":
```
Console message: [JavaScript Error: "Error: Could not establish connection. Receiving end does not exist."
{file: "moz-extension://f0d0d3ec-6815-4d78-aa83-3516814353a2/script.js" line: 2}]
```
This patch just change the order of those two promise, making sure that the browser.runtime.onMessage will be registered by the time the content script is going to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D119175
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
Also switch to removing the quotes and command-line parameters from the command
string obtained from the registry before comparing it to our path, instead of
*adding* those things to our path, to make the comparison more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D114383
This patch moves code that sets the background of the browser toolbars into
one place. It also removes some non-Proton Windows-only code rather than
updating it for this.
Differential Revision: https://phabricator.services.mozilla.com/D118658
We need to first add the scrolling metrics (scrolling_time and scrolling_distance) to the DB so we can complete the capturing and tests for those metrics (see Bug 1717920)
Differential Revision: https://phabricator.services.mozilla.com/D119119
The URLQueryStrippingListService will get initialized too late in
Fission because the 'profile-after-change' won't be triggered for
content processes in Fission. So, it won't have a complete list when the
query stripping happens because it will be initalized by then.
To address this issue, we add a content process script which will run
during the creation of content processes and it will get the service to
initialize it early so that we will have a complete list when doing the
stripping.
Differential Revision: https://phabricator.services.mozilla.com/D117376
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
I'm also removing the align=end, because the vbox is adjacent to a flex=1 vbox,
so all horizontal space will be eaten by that other box, meaning alignment of
the button is a no-op as its container is the same width as the button anyway.
Differential Revision: https://phabricator.services.mozilla.com/D119097
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
This is the only usage of viewport units in the whole browser window and
we could live without it trivially. It avoids otherwise-unnecessary
style invalidation.
In the cloned bug I've improved the style system so that we do a lot
less work, but we still need to do a full DOM walk.
Instead let's use percentages, which only need re-layout, not restyle
(viewport units compute to a pixel value, percentages compute to
themselves).
Differential Revision: https://phabricator.services.mozilla.com/D118879
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663