We are always able to produce an x height, but depending on whether the
glyph exists, we sometimes can't produce a zero glyph width.
Depends on D23423
Differential Revision: https://phabricator.services.mozilla.com/D23424
--HG--
extra : moz-landing-system : lando
While we're here, fix the measurement of ' ' and 'x' so that we don't
measure the .notdef glyph if those glyphs aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D23423
--HG--
extra : moz-landing-system : lando
nsIDOMGetUserMediaErrorCallback, nsIDOMGetUserMediaSuccessCallback,
and nsIGetUserMediaDevicesSuccessCallback were completely unused, so
they could just go away and all the code got simpler.
Differential Revision: https://phabricator.services.mozilla.com/D23782
--HG--
extra : moz-landing-system : lando
I'm a bit torn between the const-member-and-MOZ_KnownLive approach
here and just taking extra stack refs...
Differential Revision: https://phabricator.services.mozilla.com/D23778
--HG--
extra : moz-landing-system : lando
Otherwise you see font changes when hovering, which is not really desirable.
Differential Revision: https://phabricator.services.mozilla.com/D24116
--HG--
extra : moz-landing-system : lando
Add an experimental code path that makes use of the pixel local
storage extension available on many mobile GPUs.
This code path is currently disabled by default, as the support
is not complete for all primitives and blend modes. The initial
aim is to get feature parity with the existing renderer.
Once that's complete, we can take advantage of the (minimum)
12 bytes per pixel of high speed on-tile memory to store custom
data.
Clip masks are a good use case for this, since they map 1:1 with
the position of the fragment they are clipping. Using this for
clip masks allows us to handle clipping on mobile GPUs in a much
more efficient way - we can skip (a) separate render targets,
(b) target resolve (c) sample the mask texture during rendering.
Depends on D24123
Differential Revision: https://phabricator.services.mozilla.com/D24124
--HG--
extra : moz-landing-system : lando
1. Register with the root document window's parent target, since this receives events for iframes and shadow DOM. (The root document itself doesn't.)
2. Hold onto the target node when scheduling processing of the DOM event, as GetOriginalTarget returns null when we process shadow DOM events async.
Differential Revision: https://phabricator.services.mozilla.com/D21350
--HG--
extra : moz-landing-system : lando
This can happen, for example, when GetAccessibleOrContainer is called within SelectionManager::ProcessSelectionChanged due to focusing a direct child of a shadow root.
In this case, the common ancestor is the shadow root itself.
Previously, we returned null in this case because GetFlattenedTreeParent doesn't work on the shadow root itself.
Now, we check if the given node is the shadow root, and if so, we use the shadow host instead.
This prevents the "We must reach document accessible implementing text interface!" assertion in SelectionManager::ProcessSelectionChanged when a direct child of a shadow root gets focus.
Differential Revision: https://phabricator.services.mozilla.com/D21349
--HG--
extra : moz-landing-system : lando
We should catch these issues ASAP. This NS_ASSERTION also bit me in the past.
Differential Revision: https://phabricator.services.mozilla.com/D24115
--HG--
extra : moz-landing-system : lando
This is from Chromium's change log:
.mobileconfig files gives powerful controls over both system settings
and Chrome settings on MacOS, with a fairly straightforward installation process.
Differential Revision: https://phabricator.services.mozilla.com/D24285
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
Despite its name and apparent use LocalAllocPolicy could only handle a single call to Alloc() at a time which was okay due to how it was used by the MediaFormatReader.
However, we do want to handle multiple calls to Alloc().
These changes allow to perform simultaneous requests and have them be processed one at a time serially.
Differential Revision: https://phabricator.services.mozilla.com/D23651
--HG--
extra : moz-landing-system : lando
The test case triggers MOZ_ASSERT(!IsFramePartOfIBSplit(aParentFrame))
in MaybeRecreateForColumnSpan() because WipeContainingBlock() returns
early when the FrameConstructionItemList is empty. Thus, it doesn't wipe
the aParentFrame even if it's part of an IB split.
An empty FrameConstructionItemList constructs no frames. Therefore,
MaybeRecreateForColumnSpan() doesn't need to do anything if aFrameList is empty
since an empty frame list cannot contain any column-span.
Differential Revision: https://phabricator.services.mozilla.com/D23820
--HG--
extra : moz-landing-system : lando
Add profiler marker to show when VideoSink sends frames to compositor
and when it discards frames that are outdated according to current
audio position.
Differential Revision: https://phabricator.services.mozilla.com/D22792
--HG--
extra : moz-landing-system : lando
Replace a couple of popup methods so that they call dirtyFrame(), so that reflows happen deterministically.
Differential Revision: https://phabricator.services.mozilla.com/D23734
--HG--
extra : moz-landing-system : lando
Alex Gaynor
Cameron McCormack
Boris Zbarsky
Emilio Cobos Álvarez
Glenn Watson
Narcis Beleuzu
Brindusan Cristian
James Teh
Dimi Lee
Mike Hommey
Jean-Yves Avenard
Ting-Yu Lin
John Lin
Mike Conley
Jason Laster
Brad Werth
Jeff Walden
Drew Willcoxon