All uses of OwningCompileOptions now are initialized from copy() so
remove the now-unused setters.
Differential Revision: https://phabricator.services.mozilla.com/D35080
--HG--
extra : moz-landing-system : lando
Initializing OwningCompileOptions directly will soon be deprecated in
order to have consistent defaults. This results in more consistent
behavior of experimental features that are enabled based on realm flags.
Differential Revision: https://phabricator.services.mozilla.com/D35071
--HG--
extra : moz-landing-system : lando
StaticPrefs are fully initialized with Preferences, which is instantiated via XPCOM. It is required as such to initialize xpcom first.
Depends on D35263
Differential Revision: https://phabricator.services.mozilla.com/D35264
--HG--
extra : moz-landing-system : lando
We can initialize the StaticPrefs as soon as the SharedMap object is created outside the parent process.
Additionally when resetting the preferences to their default values, we no longer modify the `Once` StaticPrefs as they are immutable, only the underlying preference.
Differential Revision: https://phabricator.services.mozilla.com/D35263
--HG--
extra : moz-landing-system : lando
Attributes that are related to Fluent-based strings intentionally weren't moved to element.dataset.
Differential Revision: https://phabricator.services.mozilla.com/D35113
--HG--
extra : moz-landing-system : lando
I named the INI file parameter "FallbackPage" so that people building these
configurations can quickly understand what this URL is for and don't have to
figure out what "manual download" means.
Differential Revision: https://phabricator.services.mozilla.com/D34359
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10.17 [1], if we have tried both direction and there is no place to put the cue inside the rendering area without overlapping with other cues or the boundary of rendering area, then we have to discard all CSS boxes, which means that we should not display this cue.
Therefore, I added the cue's text content in `very_long_cue.vtt` in order to let it exceed the boundary of the rendering area during display.
[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings
Differential Revision: https://phabricator.services.mozilla.com/D33358
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10.17 [1], if we have tried both direction and there is no place to put the cue inside the rendering area without overlapping with other cues or the boundary of rendering area, then we have to discard all CSS boxes, which means that we should not display this cue.
[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings
Differential Revision: https://phabricator.services.mozilla.com/D33729
--HG--
extra : moz-landing-system : lando
Right now we do a lot of useless string copying. In order to avoid transcoding
to utf-16 during layout, make sure to use nsCString at a few related places.
I may revisit this since we're storing other line names as atoms in some places.
So it may be better to just use atoms everywhere.
But that'd be a different patch either way.
Depends on D35116
Differential Revision: https://phabricator.services.mozilla.com/D35117
--HG--
extra : moz-landing-system : lando
This workaround hands the top-level browser to nsContextMenu rather than the
mozbrowser in the RDM case. We need to do that since RDM does a lot of work
to make the inner mozbrowser _seem_ like the top-level browser, including
proxying messages from that top-most browser to the underlying mozbrowser.
This workaround makes us consistent with that model, and will have to do until
we can get bug 1559456 fixed.
Depends on D35077
Differential Revision: https://phabricator.services.mozilla.com/D35078
--HG--
extra : moz-landing-system : lando
In the content process case, preventing default stops the context menu event from being dispatched
within remote iframes, which is what causes bug 1558506.
In the parent process case, preventing default stops the nsXULPopupListener from opening the context
menu for us when we don't want ContextMenuParent to handle it, which we don't want to do.
Differential Revision: https://phabricator.services.mozilla.com/D35077
--HG--
extra : moz-landing-system : lando
This allows freelist randomization on a per-arena basis, by supplying parameters to
arena creation.
It uses an xorshift PRNG with a 128-bit state. It is not cryptographically secure. An
attacker who can observe outputs of the RNG, or read its state, is already in a position
to bypass the randomization applied. At the same time we make its state 128 bit to prevent
a trivial bypass if one or two outputs are observed.
The way a run selects masks to check has not been modified, so the randomization is limited
to at most 32 bits in the current mask being tested. It should be noted that while allocations
from the same run may now be non deterministic (up to the maximum entropy as previously
stated), an attacker who can perform multiple allocations will still be able to allocate
a targeted free region (for example while exploiting a use after free vulnerability in the
DOM). Non deterministic allocations will only impede an attacker who has less control over
how they allocate a targeted free region, and may provide some benefit during exploitation
of a heap based buffer overflow vulnerability where the attacker wishes to construct a
precise layout of regions pre overflow.
Differential Revision: https://phabricator.services.mozilla.com/D32219
--HG--
extra : moz-landing-system : lando
I wasn't able to produce a situation in which this change matters, so
I'm not certain that it's necessary, but it seems to be the correct
thing to do given the problem fixed in nsGfxScrollFrame.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D31864
--HG--
extra : moz-landing-system : lando
The work for the antecedent patch led me to stumble on a problem where
we were not correctly stopping autoscroll. This was also due to a
renderroot mismatch, which this patch addresses. The call comes through
nsBaseWidget no matter what, it seems, so using mWrRootId.mRenderRoot
seems to be incorrect. I couldn't see a more elegant fix than this.
Differential Revision: https://phabricator.services.mozilla.com/D31863
--HG--
extra : moz-landing-system : lando
There's two things going on here. 1) nsGfxScrollFrame is getting the
wrong renderroot, because it's not correctly recursing up the frame
tree. 2) Hiding behind that problem is that if we do correctly assign
the renderroot, we end up blocking on both render roots updating if
we don't, say, have a horizontal scroll option, because that leaves
us with a wr::RenderRoot::Default. 2.1) We then still end up blocking
on the default renderroot because we initialize the selector with
WebRenderBridgeParent's mRenderRoot.
Differential Revision: https://phabricator.services.mozilla.com/D31858
--HG--
extra : moz-landing-system : lando
Changes:
- rename the task name from windows10-64-ux to `windows10-64-ref-hw-2017`
- change `hardware` worker type to use the new reference hardware
Differential Revision: https://phabricator.services.mozilla.com/D35262
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
A lot of failures occurs in `org.mozilla.geckoview.test.TextInputDelegateTest.inputConnection` when getting composition string. This tests doesn't wait for `compositionupdate`, so we should listen this event to wait for updating composition string.
Differential Revision: https://phabricator.services.mozilla.com/D34812
--HG--
extra : moz-landing-system : lando
Previously we were hardcoding to disable on AMD. Modern MacOS versions
don't have MSAA corruption, and anything we find that does should go on
the downloadable blocklist instead.
Differential Revision: https://phabricator.services.mozilla.com/D34986
--HG--
extra : moz-landing-system : lando
This patch adds:
* tests that we restart the TRR connection if it gets abnormally shut down
* a way to terminate the TRR connection when attempting to resolve closeme.com
* makes sure that resolving excluded domains with the DISABLE_TRR flag does
not fail. Before this we would return an error code without checking the
excluded domains first.
Differential Revision: https://phabricator.services.mozilla.com/D35076
--HG--
extra : moz-landing-system : lando
The top-level App component forcefully resets focus to the console input when something in the output gains focus, e.g disclosure toggles, and the clear output button.While this is useful for mouse users when typing, it breaks reading flow for screen reader users when reviewing output, being sent back to input when interacting with disclosures.
This commit prevents the unwanted focus behaviour when clicking by suppressing it in an onMouseDown, and prevents the click event from bubbling to the App component so focus doesn't get reset.
Differential Revision: https://phabricator.services.mozilla.com/D28178
--HG--
extra : moz-landing-system : lando
Ted Campbell
Ed Lee
Dão Gottwald
Jean-Yves Avenard
Mathieu Leplatre
Jared Wein
Brian Grinstead
Patrick Brosset
Matt Howell
Narcis Beleuzu
Bob Owen
Masatoshi Kimura
alwu
Emilio Cobos Álvarez
Mike Conley
Tom Ritter
sotaro
Doug Thayer
Edwin Gao
Tarek Ziadé
Tom Tung
Alex Chronopoulos
Gabriele Svelto
Brendan Dahl
Makoto Kato
Jeff Gilbert
Valentin Gosu
Christoph Kerschbaumer
Sebastian Hengst
Dickson Tan