The test was originally using BrowserTestUtils.waitForNewWindow with an argument for
the expected initial tab URL which was a function rather than a string. This helper
function never expects a function, but transparently passed it along to browserLoaded,
which _can_ handle a function, so everything worked.
With the privileged about content process enabled, the waitForNewWindow code fell
down a codepath that doesn't handle the function parameter at all, and causes the
test to wait for a XULFrameLoaderCreated event that will never fire.
This patch adjusts the test to no longer pass the function to waitForNewWindow, since
it never supported having a function passed to it. Instead, we do the check for the
initial tab URL after the window has been opened.
Differential Revision: https://phabricator.services.mozilla.com/D64603
--HG--
extra : moz-landing-system : lando
Add a new label to collect the number of BFCached documents that are not
the only top level documents in their BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D65790
--HG--
extra : moz-landing-system : lando
Handle rfc822Name and iPAddress subjectAltNames, and replace "[object
Object]" with an explicit "unsupported" string for otherName.
Differential Revision: https://phabricator.services.mozilla.com/D65749
--HG--
extra : moz-landing-system : lando
This removes the obsolete backend. Notes on some of the less obvious changes
made as part of this patch:
- some of the gFoo style getters in Blocklist.jsm were only used by the XML
version of the blocklist; I've removed them and tried to remove spurious
settings of those properties in the remaining tests.
- some utility methods (e.g. distribution information getters) were also only
used for the XML version (for the update URL).
- it's no longer necessary to test switching implementations.
- in browser/base/content/test/plugins/, we ran some tests from two manifests
in order to run them with both blocklist backends. The simplest way of
reducing this back down to one was to remove the remote-settings one. If I'd
been more future-oriented when I created the duplication, perhaps I would
have moved the XML version out into a different manifest instead, but I
didn't, so now it looks like we're removing the modern one, whereas really
we're going to be running the modern one as part of the "normal" tests and
we're no longer running the "old" tests.
- removed all mentions I could see of extensions.blocklist.url which is no
longer used for anything.
- per https://bugzilla.mozilla.org/show_bug.cgi?id=1016555#c23, updated
references for the OneCRL timing and how it relates to blocklist updates.
Differential Revision: https://phabricator.services.mozilla.com/D64933
--HG--
extra : moz-landing-system : lando
Bug 1603714 showed there were `UntrustedModulesData` instances in which a load
event pointed to a module which did not exist in the modules list.
This patch adds `MOZ_DIAGNOSTIC_ASSERT` to the following places to narrow down
when it happened.
Given that the number of the impected users seems big (~200 crashes/day on Nightly),
we activate the assers with a probability of 1/16 (~12.5 crashes/day).
1. When processing load events
1-1. [Content] `UntrustedModulesProcessor::CompleteProcessing:`
Verify events of a trusted module were eliminated by `GetModulesTrust`
1-2. [Content] `UntrustedModulesData::AddNewLoads`:
Verify a new `ModuleRecord` matches the event
1-3. [Content] `UntrustedModulesProcessor::CompleteProcessing`:
Verify processed data after new items were appended.
2. When processed data is sent
2-1. [Content] `UntrustedModulesProcessor::GetAllProcessedData`:
Verify processed data before serialization.
2-2. [Content] `ParamTraits<mozilla::UntrustedModulesData>::WriteEvent`:
Verify processed data before transferring to the browser process
2-3. [Browser] `ParamTraits<mozilla::UntrustedModulesData>::ReadEvent`:
A final point to catch this integrity problem. We had an IPC error here.
Differential Revision: https://phabricator.services.mozilla.com/D59964
--HG--
extra : moz-landing-system : lando
If an addon is updated and moves permissions between required to optional, we
want to retain the previously granted permission so the extension does not have to
request the permission from the user again. We also handle permission removal
and changes to preferences based on permissions.
Differential Revision: https://phabricator.services.mozilla.com/D64696
--HG--
extra : moz-landing-system : lando
Bug 1603714 showed there were `UntrustedModulesData` instances in which a load
event pointed to a module which did not exist in the modules list.
This patch adds `MOZ_DIAGNOSTIC_ASSERT` to the following places to narrow down
when it happened.
Given that the number of the impected users seems big (~200 crashes/day on Nightly),
we activate the assers with a probability of 1/16 (~12.5 crashes/day).
1. When processing load events
1-1. [Content] `UntrustedModulesProcessor::CompleteProcessing:`
Verify events of a trusted module were eliminated by `GetModulesTrust`
1-2. [Content] `UntrustedModulesData::AddNewLoads`:
Verify a new `ModuleRecord` matches the event
1-3. [Content] `UntrustedModulesProcessor::CompleteProcessing`:
Verify processed data after new items were appended.
2. When processed data is sent
2-1. [Content] `UntrustedModulesProcessor::GetAllProcessedData`:
Verify processed data before serialization.
2-2. [Content] `ParamTraits<mozilla::UntrustedModulesData>::WriteEvent`:
Verify processed data before transferring to the browser process
2-3. [Browser] `ParamTraits<mozilla::UntrustedModulesData>::ReadEvent`:
A final point to catch this integrity problem. We had an IPC error here.
Differential Revision: https://phabricator.services.mozilla.com/D59964
--HG--
extra : moz-landing-system : lando
* Dont flag a form as user-modified when the input is from autofilling a login
* Avoid sending PasswordEditedOrGenerated messages to the parent from non-user-modified forms.
Differential Revision: https://phabricator.services.mozilla.com/D65668
--HG--
extra : moz-landing-system : lando
Abort it before writing the cache to avoid potentially writing a incomplete cache.
Differential Revision: https://phabricator.services.mozilla.com/D65723
--HG--
extra : moz-landing-system : lando
Expire favicons older than 6 months when:
* they are for permanently redirecting urls, that are unlikely to receive
updated favicons
* they are for urls with refs (often mail, docs) that have a fallback root
favicon for their origin
Expiration happens in chunks, mostly on idle-daily.
Differential Revision: https://phabricator.services.mozilla.com/D65308
--HG--
extra : moz-landing-system : lando
This also bumps the cache version numbers, because we currently need to cache the telemetry id as part of the engine info.
Differential Revision: https://phabricator.services.mozilla.com/D65134
--HG--
extra : moz-landing-system : lando
These methods were used for media control and audio focus on Fennec, and we don't need them anymore.
Differential Revision: https://phabricator.services.mozilla.com/D65262
--HG--
extra : moz-landing-system : lando
These tests are used to test `SUSPENDED_PAUSE`, which is used for the old audio focus mechanism on Fennec, and `SUSPENDED_PAUSE_DISPOSABLE`, which is used for the media control on Fennec.
As we don't use them anymore, we can remove these tests.
Differential Revision: https://phabricator.services.mozilla.com/D65261
--HG--
extra : moz-landing-system : lando
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
The telemetry session ID annotation is only used to correlate crash pings with
main pings, it does not need to be sent along with crash reports as we have no
use for it there.
Differential Revision: https://phabricator.services.mozilla.com/D65446
--HG--
extra : moz-landing-system : lando
The signatures are used for Firefox's FIPS mode. But they are actually
mostly a longstanding lie: people interested in the FIPS mode ought to
use a FIPS-validated version of the affected NSS libraries, and the last
validated version is now more than 10 years old. Needless to say,
Firefox doesn't ship anything close to the validated version anymore.
Furthermore, at the moment, the build system doesn't support generating
these signature while cross compiling. We have been cross compiling
Firefox for Mac for 5 years give or take, which means it hasn't been
possible to enable FIPS mode in Firefox on Mac out of the box for that
long.
As we are moving towards cross compiling for Windows, the question
whether we should keep those signatures has risen again. And if we're
going to remove them for the cross compiled platforms, we might as well
remove them everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D65468
--HG--
extra : moz-landing-system : lando
This patch prevents the URL formatter from setting empty values for distribution data.
Differential Revision: https://phabricator.services.mozilla.com/D65368
--HG--
extra : moz-landing-system : lando
* Dont flag a form as user-modified when the input is from autofilling a login
* Avoid sending PasswordEditedOrGenerated messages to the parent from non-user-modified forms.
Differential Revision: https://phabricator.services.mozilla.com/D64843
--HG--
extra : moz-landing-system : lando
Even though e10s is turned on in GeckoView, we do not yet support the extension
process; we should skip these tests in that case.
Differential Revision: https://phabricator.services.mozilla.com/D65418
--HG--
extra : moz-landing-system : lando
* Dont flag a form as user-modified when the input is from autofilling a login
* Avoid sending PasswordEditedOrGenerated messages to the parent from non-user-modified forms.
Differential Revision: https://phabricator.services.mozilla.com/D64843
--HG--
extra : moz-landing-system : lando
Revision c73bb7b4a284 was originally intended to do this, but accidentally extended a
separate but related probe. Unfortunately, extending that probe didn't fix the original
problem, which is a test failure on uplift simulation.
This patch _actuall_ extends the FX_TAB_CLOSE_TIME_NO_ANIM_MS probe to version 80.
Differential Revision: https://phabricator.services.mozilla.com/D64955
--HG--
extra : moz-landing-system : lando
This patch prevents the URL formatter from setting empty values for distribution data. It also prevents any non-url-encoded value from being substituted into the URL.
Differential Revision: https://phabricator.services.mozilla.com/D65368
--HG--
extra : moz-landing-system : lando
The test passes on nightly because the condition actually checks specifically for nightly. On non-nightly the test fails because although it mocks the channel with withFakeChannel, the code under test doesn't respect that.
Differential Revision: https://phabricator.services.mozilla.com/D65303
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
Occasionally, we might try to apply synced bookmarks when a transaction
is already in progress. Consider something like this:
1. The user clicks the star button, which adds a bookmark to the
default folder. Under the hood, this runs a transaction to
completion—`BEGIN`, some `INSERT`s and `UPDATE`s, then `COMMIT`.
2. The `item-added` observer notification kicks off a sync.
3. The user, with the star UI still open, picks a new folder for the
bookmark. This moves the bookmark under the hood.
4. To move the bookmark, we run `BEGIN` on the Places connection's
async thread. Remember, `Sqlite.jsm` runs async statements one at a
time.
5. Concurrently, the merge runnable is scheduled on the async thread.
It's not aware of the `Sqlite.jsm` transaction queue, and doesn't
know that a transaction for the move is already open.
6. The merger tries to open its own transaction with `BEGIN`, fails
noisly, and returns a "cannot start a transaction within a
transaction" error back to the main thread.
7. The move transaction started in (4) runs to completion, updating
the new bookmark's parent and committing the changes.
This is a case of bad timing—retrying the sync once the user finishes
making changes will work—but reports errors in telemetry and logs.
This commit downgrades those to warnings.
Depends on D63732
Differential Revision: https://phabricator.services.mozilla.com/D63734
--HG--
extra : moz-landing-system : lando
Previously, `mozIStorageConnection#transactionInProgress` returned true
only if a transaction was started via `beginTransaction()`. This meant
that manually executing `BEGIN`, as `Sqlite.jsm` and the Rust bindings
do, wouldn't accurately report if a transaction was in progress.
Similarly, the flag wasn't accurate in cases where SQLite automatically
rolled back a transaction.
Fortunately, SQLite provides the `sqlite3_get_autocommit()` function,
which we can use to determine if a transaction is open or not. This
commit refactors the `transactionInProgress` getter, along with all
`Connection` methods that depend on it, to use the SQLite API instead
of managing that state on the connection. `mozStorageTransaction` and
`Sqlite.jsm` still use their own flags to decide whether to commit
their transactions, for reasons explained in the IDL comment.
This commit also moves `transactionInProgress` to
`mozIStorageAsyncConnection`, so that `Sqlite.jsm` can use it, and
exposes it to Rust.
Differential Revision: https://phabricator.services.mozilla.com/D63732
--HG--
extra : moz-landing-system : lando
MOZ_PROFILE_GENERATE is already defined in mozilla-config.h and doesn't
need to be re-defined by the moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D65210
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
The regular Android theme doesn't support it, so it does nothing.
With the non-native theme, which supports scrollbars, it'd look like windows
scrollbars, which we don't want.
Differential Revision: https://phabricator.services.mozilla.com/D65138
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Includes fixes for the following bugs:
- "auto-update-config-change" notification is never sent because it never updates its cached value so it always thinks the value is uninitialized, at state in which it does not send the notification.
- maybeUpdateAutoConfigChanged doesn't send the first notification because the value hasn't changed yet, just been set. But this is only true on Windows. On other OS's, the function is only called when the value changes.
- If a non-Windows user changes the app.update.auto pref value, it effectively changes the value of the auto update setting but doesn't generate a "auto-update-config-change" notification.
- Minor cleanup of an unnecessary bind call.
Differential Revision: https://phabricator.services.mozilla.com/D63983
--HG--
extra : moz-landing-system : lando
Includes fixes for the following bugs:
- "auto-update-config-change" notification is never sent because it never updates its cached value so it always thinks the value is uninitialized, at state in which it does not send the notification.
- maybeUpdateAutoConfigChanged doesn't send the first notification because the value hasn't changed yet, just been set. But this is only true on Windows. On other OS's, the function is only called when the value changes.
- If a non-Windows user changes the app.update.auto pref value, it effectively changes the value of the auto update setting but doesn't generate a "auto-update-config-change" notification.
- Minor cleanup of an unnecessary bind call.
Differential Revision: https://phabricator.services.mozilla.com/D63983
--HG--
extra : moz-landing-system : lando
Occasionally, we might try to apply synced bookmarks when a transaction
is already in progress. Consider something like this:
1. The user clicks the star button, which adds a bookmark to the
default folder. Under the hood, this runs a transaction to
completion—`BEGIN`, some `INSERT`s and `UPDATE`s, then `COMMIT`.
2. The `item-added` observer notification kicks off a sync.
3. The user, with the star UI still open, picks a new folder for the
bookmark. This moves the bookmark under the hood.
4. To move the bookmark, we run `BEGIN` on the Places connection's
async thread. Remember, `Sqlite.jsm` runs async statements one at a
time.
5. Concurrently, the merge runnable is scheduled on the async thread.
It's not aware of the `Sqlite.jsm` transaction queue, and doesn't
know that a transaction for the move is already open.
6. The merger tries to open its own transaction with `BEGIN`, fails
noisly, and returns a "cannot start a transaction within a
transaction" error back to the main thread.
7. The move transaction started in (4) runs to completion, updating
the new bookmark's parent and committing the changes.
This is a case of bad timing—retrying the sync once the user finishes
making changes will work—but reports errors in telemetry and logs.
This commit downgrades those to warnings.
Depends on D63732
Differential Revision: https://phabricator.services.mozilla.com/D63734
--HG--
extra : moz-landing-system : lando
Previously, `mozIStorageConnection#transactionInProgress` returned true
only if a transaction was started via `beginTransaction()`. This meant
that manually executing `BEGIN`, as `Sqlite.jsm` and the Rust bindings
do, wouldn't accurately report if a transaction was in progress.
Similarly, the flag wasn't accurate in cases where SQLite automatically
rolled back a transaction.
Fortunately, SQLite provides the `sqlite3_get_autocommit()` function,
which we can use to determine if a transaction is open or not. This
commit refactors the `transactionInProgress` getter, along with all
`Connection` methods that depend on it, to use the SQLite API instead
of managing that state on the connection. `mozStorageTransaction` and
`Sqlite.jsm` still use their own flags to decide whether to commit
their transactions, for reasons explained in the IDL comment.
This commit also moves `transactionInProgress` to
`mozIStorageAsyncConnection`, so that `Sqlite.jsm` can use it, and
exposes it to Rust.
Differential Revision: https://phabricator.services.mozilla.com/D63732
--HG--
extra : moz-landing-system : lando
This patch converts the BMP decoder to use SurfacePipe instead of using
AllocateFrame and Downscaler directly. As a result, it now uses the
accelerated premultiplication path, honours the
SurfaceFlags::NO_PREMULTIPLY_ALPHA flag, and allows for a path forward
to support color management and clipboard better.
Differential Revision: https://phabricator.services.mozilla.com/D64866
--HG--
extra : moz-landing-system : lando
When socket process is enabled, parent process needs some information in `CommonSocketControl`, but `CommonSocketControl` is only accessible in socket process.
This patch moves some data members from `CommonSocketControl` to `nsTransportSecurityInfo` and make it possible for parent process to get the needed data.
Differential Revision: https://phabricator.services.mozilla.com/D64084
--HG--
extra : moz-landing-system : lando
This is the cheapest solution to unblock the feature. These attributes probably shouldn't
be [noscript] to begin with, which is bug 1619242. The test addition is really simple and
ensures this test is covered. I filed bug 1619244 for rewriting this test, with the purpose
of making it easier to add additional cookie test cases.
Differential Revision: https://phabricator.services.mozilla.com/D64943
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 01548614184b (bug 1602773)
Backed out changeset 430c8e6b0c5a (bug 1602773)
Backed out changeset 1b4e2b044fcd (bug 1602773)
The :not() clause unhelpfully influences the specificity of the selector for menulists in general.
However, it is not necessary anyway, because xul.css overrides the min-height to 0 for [popuponly]
menulists using !important.
Differential Revision: https://phabricator.services.mozilla.com/D64922
--HG--
extra : moz-landing-system : lando
This commit changes `Store::local_row_to_item` to validate local URLs,
and flags items with malformed URLs as invalid. These items are either
replaced with valid remote copies, if they exist, or deleted if not.
Additionally, `BaseBookmarksStore#_calculateIndex` no longer throws
when determining the sort index for an item with an invalid URL.
As an aside, we use the `url` crate to parse URLs. This is the same
crate as used by `MozURL`, which, in turn, backs the JS `URL`
constructor...so URLs should be validated the same way in Rust and JS.
Differential Revision: https://phabricator.services.mozilla.com/D64695
--HG--
extra : moz-landing-system : lando
The test was originally using BrowserTestUtils.waitForNewWindow with an argument for
the expected initial tab URL which was a function rather than a string. This helper
function never expects a function, but transparently passed it along to browserLoaded,
which _can_ handle a function, so everything worked.
With the privileged about content process enabled, the waitForNewWindow code fell
down a codepath that doesn't handle the function parameter at all, and causes the
test to wait for a XULFrameLoaderCreated event that will never fire.
This patch adjusts the test to no longer pass the function to waitForNewWindow, since
it never supported having a function passed to it. Instead, we do the check for the
initial tab URL after the window has been opened.
Differential Revision: https://phabricator.services.mozilla.com/D64603
--HG--
extra : moz-landing-system : lando
The keypress events aren't firing on the dialog in OSX, so closing the dialog via a keyboard
shortcurt isn't currently working.
Differential Revision: https://phabricator.services.mozilla.com/D63607
--HG--
extra : moz-landing-system : lando
Default engines should be after distribution engines. Although all the distributions list the default engine as the first engine, if we ever specify a separate private engine, this may get inserted into the second position, which distributions wouldn't normally expect, hence breaking their orders.
Differential Revision: https://phabricator.services.mozilla.com/D64668
--HG--
extra : moz-landing-system : lando
This aligns with the behaviour before bug 1595915 since password generation was nested under the disabled "Fill (username|password)" option.
Differential Revision: https://phabricator.services.mozilla.com/D64405
--HG--
extra : moz-landing-system : lando
I think during the All Hands in Berlin you might have suggested to do this in nsPresContext::DefaultBackgroundColor,
but this seems a bit more targeted and not a header.
I haven't try tested this yet, so this more of a feedback?
Differential Revision: https://phabricator.services.mozilla.com/D63801
--HG--
extra : moz-landing-system : lando