Use ApplyUnicodeExtensionToTag to add the collation keyword instead of manually
splicing the keyword into the language tag.
Differential Revision: https://phabricator.services.mozilla.com/D51854
--HG--
extra : moz-landing-system : lando
This will allow us to reuse this function to insert the calendar and numberingSystem
options into the locale in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D51853
--HG--
extra : moz-landing-system : lando
The devtools highlighter is broken with browser.xhtml when scroll frames
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D52104
--HG--
extra : moz-landing-system : lando
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
--HG--
extra : moz-landing-system : lando
When using an HTML root these tests failed because the source drag element
is not visible.
Differential Revision: https://phabricator.services.mozilla.com/D50674
--HG--
extra : moz-landing-system : lando
Previously we were returning the documentElement in order to match the old XUL behavior.
Now that we have a document.body we can just follow the normal HTML convention.
Differential Revision: https://phabricator.services.mozilla.com/D34021
--HG--
extra : moz-landing-system : lando
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
