`TextEditor::SetWrapWidth` already sets `nsIDocumentEncoder`'s wrap
column which is propagated to `nsPlainTextSerializer`. So this should be
a safe change.
Differential Revision: https://phabricator.services.mozilla.com/D46008
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Fix scissor rect being incorrect during pinch zoom due to floating
point inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D46743
--HG--
extra : moz-landing-system : lando
Even if `element.focus` is called from chrome, we always open virtual keyboard.
But I would like to change this behaviour that virtual keyboard isn't opened
via `element.focus` that is chrome script.
Depends on D44104
Differential Revision: https://phabricator.services.mozilla.com/D44105
--HG--
extra : moz-landing-system : lando
Actually, CAUSE_UNKNOWN_CHROME is set when caller is chrome process. I would
like to change that this value is called from chrome or native.
Differential Revision: https://phabricator.services.mozilla.com/D44104
--HG--
extra : moz-landing-system : lando
This test assumes that the initial value of `border-image-outset` is '0px' but it is '0'.
'0' does not interpolate with '2px' in a <number> | <length> context since it is treated
as a <number> per spec.
This issue arose because Blink treats the initial value of `border-image-outset` as '0px'.
This is a known bug: https://crbug.com/898203
Differential Revision: https://phabricator.services.mozilla.com/D46722
--HG--
extra : moz-landing-system : lando
This is the patch that tests and fixes this bug. If we execute the error
case because the OS refused to create a thread we would create a nested
AutoLockHelperThreadsState and violate mutex orderings. We fix this by
reducing the AutoLockHelperThreadsState scope in ensureInitalized().
Also:
+ Use OOM testing to fail thread creation.
+ Remove the unsafe-OOM region from Thread::init(), it isn't needed anyway.
Differential Revision: https://phabricator.services.mozilla.com/D46563
--HG--
extra : moz-landing-system : lando
Also make DestroyHelperThreadsState() idempotent so we can call it from the
test regardless of what state the helper thread state is in.
Other changes to HelperThreads.cpp make this code safer when allocations
fail.
Differential Revision: https://phabricator.services.mozilla.com/D46562
--HG--
extra : moz-landing-system : lando
We should end the test once the OOM simulation has found the last allocation
it can instrument, not when the context is created. This exercises 3 extra
allocations (they may be in the DestroyContext).
Also:
* Print a + or a . to standard output to show if a context was
successfully created or not for each iteration.
* Rename this so all the OOM tests have OOM in their name.
Differential Revision: https://phabricator.services.mozilla.com/D46561
--HG--
extra : moz-landing-system : lando
Fragmentation spec already has a paragraph describing this behavior.
DONTBUILD because this is a comment only change.
Differential Revision: https://phabricator.services.mozilla.com/D46691
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
Our build toolchains don't contain libstdc++ headers for aarch64, so our
aarch64 builds rely on whatever libstdc++ headers the system has
installed. To bring in newer headers on our aarch64 builds, then, we
need to update the system images for those builds, which this patch does.
Depends on D45861
Differential Revision: https://phabricator.services.mozilla.com/D45862
--HG--
extra : moz-landing-system : lando
On older Debian versions, `libstdc++-$VERSION-dev` is implicitly brought
in by other development packages. On newer versions, this dependency
has been removed. Let's go ahead and explicitly declare which version
we want to install for each Debian version.
Differential Revision: https://phabricator.services.mozilla.com/D45861
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
The user may be in the process of setting up Sync so prompting to setup login Sync from a CFR would be untimely.
Differential Revision: https://phabricator.services.mozilla.com/D46252
--HG--
extra : moz-landing-system : lando
Thanks to the promisifying of SendCrossProcessRedirect we no longer needs callback to DocumentChannelParent from nsHttpChannelParent. So we can remove the interface that allowed to do so.
Differential Revision: https://phabricator.services.mozilla.com/D46174
--HG--
rename : netwerk/base/nsICrossProcessSwitchChannel.idl => netwerk/base/nsIProcessSwitchRequestor.idl
extra : moz-landing-system : lando
nsViewSourceChannel will never trigger a change of process. So we can remove this interface from nsViewSourceChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46160
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
There's only one consumer of these promises. It doesn't need to be non-exclusive.
Differential Revision: https://phabricator.services.mozilla.com/D46016
--HG--
extra : moz-landing-system : lando
Will allow for SessionStore.jsm process switching to be used by other objects than nsHttpChannel.
Differential Revision: https://phabricator.services.mozilla.com/D46015
--HG--
extra : moz-landing-system : lando
This is a stepped transition ; as SessionStore currently only knows how to deal with nsHttpChannel we have to go through the redirect only if the current channel is a nsHttpChannel.
In a followup change we will allow SessionStore to directly deal with the DocumentParentProcess.
Differential Revision: https://phabricator.services.mozilla.com/D46014
--HG--
extra : moz-landing-system : lando
