The way this test works is, it loads a page, then it navigates to
another page and exits. The mochitest browser-chrome leak detector
will report a leak if the first page isn't freed by the end of the
test.
To make this Fission-compatible, I first changed the page we navigate
to to be same-origin. This means that we won't tear down the original
process immediately when we navigate, which will break the various
test harness stuff.
Secondly, I enable the dom.ipc.keepProcessesAlive.webIsolated
preference, which means that the content process won't be torn down
immediately. If this pref is not set, then the usual process reuse
ends up destroying the window before the test ends, whether or not it
leaks.
I verified that this test fails when the patch from bug 1336811 is
backed out, both with and without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D51944
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
Also rename surface_position_update to surface_position_needs_update to make it more clear.
Differential Revision: https://phabricator.services.mozilla.com/D52171
--HG--
extra : moz-landing-system : lando
The problem is that we change the slice budget after passing it to gcstats::AutoGCSlice. Later on we compare the actual time taken against the old value and think we've overrun our budget. The fix is to make the change earlier.
Depends on D52161
Differential Revision: https://phabricator.services.mozilla.com/D52162
--HG--
extra : moz-landing-system : lando
Significantly, we remove the TestRunner stuff since we have nice things like
add_task now.
Depends on D50850
Differential Revision: https://phabricator.services.mozilla.com/D50851
--HG--
extra : moz-landing-system : lando
This test is race-y, and doesn't actually ensure that the migration has completed
before doing its checks.
When I modified the test to wait for the migration to complete, the test actually
failed. Which isn't great news.
The good news, however, is that the migration took place back in Firefox 21, and
so we can probably remove all of the migration code now.
I'm disabling the test for now, and filed bug 1592079 to remove the migration code
and test completely.
Depends on D45957
Differential Revision: https://phabricator.services.mozilla.com/D50850
--HG--
extra : moz-landing-system : lando
This was an ambiguity in the spec between the prose and formalism. The spec
interpreter implements it this way.
Differential Revision: https://phabricator.services.mozilla.com/D52130
--HG--
extra : moz-landing-system : lando
Threadpools run an event that then runs other events, so we need to tweak
things for GetRunningEventDelay()
Differential Revision: https://phabricator.services.mozilla.com/D44058
--HG--
extra : moz-landing-system : lando
This lets us determine the time that an event has been running, and the time
that the event spent queued - which can be used to figure out 'jank' at the
time the event was queued. For PrioritizedEventQueues, only if such queuing
would delay an input event then the queuing delay is reported.
Differential Revision: https://phabricator.services.mozilla.com/D41279
--HG--
extra : moz-landing-system : lando
AttachConsole() may change Win32 std handle values if Firefox is launched from
cmd.exe that makes discrepancy between Win32 and CRT. This patch synchronizes
both std handles.
Differential Revision: https://phabricator.services.mozilla.com/D51275
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
Seems less gnarly than the alternatives, and we'd only free it until shutdown so
not much worse, actually.
Differential Revision: https://phabricator.services.mozilla.com/D51871
--HG--
extra : moz-landing-system : lando
The existing code wasn't sound, as CSSOM objects also needed to go away before
the shared memory goes away (as they keep references to them).
This is sound assuming no presence of reference cycles introduced by CSSOM.
We may want to live with this and rely on chrome code not writing cycles like
this with UA stylesheet DOM objects.
We could explicitly drop all potentially-static objects... That seems pretty
error prone though.
Or we could also just leak the shared memory buffer, is there any reason why we
may not want to do that?
Differential Revision: https://phabricator.services.mozilla.com/D51870
--HG--
extra : moz-landing-system : lando
This situation can happen if a locale does not set a value for a localized devtools shortcut, ie writes
toolbox.elementPicker.key=
(with nothing after the = sign)
Differential Revision: https://phabricator.services.mozilla.com/D52099
--HG--
extra : moz-landing-system : lando
The debug dictionaries in MediaDebugInfo.webidl all have default values, and the intent when the debug structure is created by the C++ promise is to initialize all values, including nested dictionaries, to the provided defaults. **required** was not the right way to do this.
Differential Revision: https://phabricator.services.mozilla.com/D51822
--HG--
extra : moz-landing-system : lando
This worker-type isn't working with worker-manager, so backout the change
switching to it.
MANUAL PUSH: Prepration for testing firefox-ci cluster in advance of TCW
Differential Revision: https://phabricator.services.mozilla.com/D52119
--HG--
extra : histedit_source : 4f2689d47f25864b87abae6eeb55cc09936f4a61
This turned out not to be the culprit, but it doesn't seem unreasonable for
DropAllRules -> DropRules -> cycle-collection-stuff that ends up reentering in
the parent rule list.
It seems safer to first remove from the array / move the array to the stack,
then free the pointer, than to leave dangling pointers while we iterate through
the array.
Differential Revision: https://phabricator.services.mozilla.com/D51869
--HG--
extra : moz-landing-system : lando
We originally had a different plan related to migrating worker-types to a new cluster.
Remove the code that supported that.
Differential Revision: https://phabricator.services.mozilla.com/D52076
--HG--
extra : rebase_source : 1c0945e96add41659f56013a01d4d246e2d69dd3
extra : histedit_source : 03acebc1cc6796bd60cd472bc3c5c92a9c17f02b
MANUAL PUSH: (a) This patch will cause a ton of toolchain rebuilds, and might as well do that on central right now rather than autoland, and (b) We want to test the new Taskcluster instance today, and will be testing THAT on m-c, so we'll need this patch on m-c before we can test the new cluster as well.
tooltool at present needs to support production (legacy cluster) but its auth system is tied to that cluster.
Which means that using tooltool in the new cluster ahead of TCW is harder. We have swapped the credentials for the tooltool staging deployment to use the new tc cluster, so when we're using the taskcluster proxy we need to have it swap between legacy and new tooltool url's depending on which cluster (ROOT_URL) we're using.
This patch is intended to be ok to land on production code today, and could be backed out after the TCW when production tooltool will be configured to work with the firefox-ci cluster itself.
Differential Revision: https://phabricator.services.mozilla.com/D52089
