This test was originally written to test HTTPResponseProcessSelection before it
was hooked up into the process switch machinery. It hooks into some parts of the
process switch process which should probably be removed in the future (such as
overriding the child listener component registration), and is broken under
fission anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47313
--HG--
extra : moz-landing-system : lando
We have the `LauncherRegistryInfo` class to check the launcher process was
launched successfully on Windows by comparing the timestamps in the registry
when each process was launched.
The problem was when the process is launched from an elevated process, we
relaunch a new launcher process via shell after we updated the launcher's
timestamp. As a result, `LauncherRegistryInfo` unexpectedly disabled the
launcher process even though there was nothing wrong.
A proposed fix is to introduce delay-write to the `LauncherRegistryInfo`. With
this, `LauncherRegistryInfo::Check` modifies only the image timestamp. To update
the launcher/browser timestamps, we need to call `LauncherRegistryInfo::Commit`.
When we ask shell to relaunch a new process, we hold back commit, delegating it
to the new process.
There is another consideration needed. If something fails during `LauncherMain`,
we call `DisableDueToFailure()` to disable the launcher until the image timestamp
is changed. In such a case, we should not change the stored timestamps even
though commit is attempted. The problem is we use a different instance to call
`DisableDueToFailure()` in `HandleLauncherError`. To deal with this design,
`LauncherRegistryInfo` has a static boolean to indicate disablement happens or not.
Differential Revision: https://phabricator.services.mozilla.com/D44928
--HG--
extra : moz-landing-system : lando
test with:
`./mach run --temp-profile --setpref browser.newtabpage.activity-stream.asrouter.providers.cfr="{\"id\":\"cfr\",\"enabled\":true,\"type\":\"local\",\"localProvider\":\"CFRMessageProvider\",\"frequency\":{\"custom\":[{\"period\":\"daily\",\"cap\":10}]},\"categories\":[\"cfrAddons\",\"cfrFeatures\"],\"updateCycleInMs\":3600000}"`
for testing: Change `browser/components/newtab/lib/CFRPageActions.jsm` line 136, to `if (false)` instead of `if (resource)` or comment out that block. This is to force using the local ftl file.
- you can use the newtab devtools, set `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled=true`
- change the pref `privacy.trackingprotection.cfr-milestone.milestone-achieved=1` and `privacy.trackingprotection.cfr-milestone.milestones="1, 5000, 10000, 25000, 50000, 100000, 500000"`
- ensure at least one tracker has been saved in the database by visiting a tracking page and refreshing (this is so we can get the date it was saved from the database).
- open a new tab and click the wrench to the top right.
- change provider to "cfr" scroll down to find the milestone_message and click "show"
- I've now added a 24 hour timeout in `toolkit/components/antitracking/TrackingDBService.jsm` line 270 - you'll want to comment this out in order to see the popup.
Differential Revision: https://phabricator.services.mozilla.com/D47512
--HG--
extra : moz-landing-system : lando
Note - This was added in such a way so that any other buttons within login-item who have min-width declared are not overwritten.
Differential Revision: https://phabricator.services.mozilla.com/D49182
--HG--
extra : moz-landing-system : lando
This commit updates maintenance to change an item's GUID when changing
its type, and adds a task to insert tombstones for the old GUIDs. This
ensures that the item is synced correctly to other clients, without
throwing errors or creating duplicates. We'll still need to handle
existing items on the server; that's bug 1586434.
This commit also adds a new task to fix up NULL types, and moves
the task to remove items referencing nonexistent Place IDs _after_
the new task. This ensures we do the right thing for items without
a type, and with an `fk` that doesn't reference `moz_places.id`.
Differential Revision: https://phabricator.services.mozilla.com/D49048
--HG--
extra : moz-landing-system : lando
The TextNodeCorrespondenceRecorder stuff doesn't handle display: contents or
Shadow DOM at all. This causes a failure with an upcoming patch.
This patch fixes it and fixes related crashes like bug 1563779. This is the same
wallpaper as bug 1421807.
Differential Revision: https://phabricator.services.mozilla.com/D49138
--HG--
extra : moz-landing-system : lando
This removes the parse-time check for whether dynamic import hook has been set. There's already a runtime check for this too, previously just to support enabling/disabling dynamic import via a pref. I updated web platform tests and expectations so that use of dynamic imports in wokers is now an expected failure (previously we would time out).
Differential Revision: https://phabricator.services.mozilla.com/D45698
--HG--
extra : moz-landing-system : lando
The XBL test is being removed because it was the only remaining consumer of
xbl's implements="interfacename" in the tree, and was triggering QI on elements
for that codepath.
I've verified that a try run that MOZ_CRASHes when the C++ binding
QueryInterface implementation is invoked is green with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D48249
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
Also some minor cleanup in nsWindowWatcher, as well as a small fix,
where GetWindowByName forgot to addref its return value (as changed in
Part 1).
Differential Revision: https://phabricator.services.mozilla.com/D48976
--HG--
extra : moz-landing-system : lando
In addition to the tests added before, which test the decoding of encoded
keys, this adds test for other member functions of Key.
Differential Revision: https://phabricator.services.mozilla.com/D39005
--HG--
extra : moz-landing-system : lando
test_autocomplete_https_downgrade.html will be fixed for Fission in bug 1588091
Differential Revision: https://phabricator.services.mozilla.com/D48973
--HG--
rename : toolkit/components/passwordmgr/test/mochitest/test_autocomplete_https_upgrade.html => toolkit/components/passwordmgr/test/mochitest/test_autocomplete_https_downgrade.html
extra : moz-landing-system : lando
The previous code relied on the header label having a value property.
However, after the conversion to Fluent in bug 1563026, this is no longer the case.
Instead, use aria-labelledby, which avoids label duplication and will work irrespective of the label's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D49125
--HG--
extra : moz-landing-system : lando
browser_about_debugging_link.js is testing the page options that open (or switch) to about:debugging
from about:addons.
This test seems to be failing intermittently because there are pending RDP requests when the about:debugging
tab is being closed once the test is completed.
We already had a similar issue before and at the time daisuke provided us the test helpers currently used
in the test to wait for the tabs, workers and extensions to be populated in the store.
Unfortunately this doesn't seem enough anymore, especially with fission enabled the test is keep
failing because it seems that some new RDP requests are pending when we are closing the tab
(from the stacktrace it seems that the pending requests are triggered by the "processes updates listener").
The waitForRequestsToSettle test helper used in some other about:debugging tests seems to be able to fix
the intermittent failure (trying on linux64 debug locally it passed test-verify multiple times).
Differential Revision: https://phabricator.services.mozilla.com/D49015
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando