It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
When window is resized, the cue would usually be zoomed in or out automatically with the video and keep its relative position to video.
However, if video is being applied the explicit percentage value on its 'width' or 'height', we have to recompute cue's position in this situation, because the width or height of the video would be scaled again after applied the first size scaled which is caused by resizing.
Differential Revision: https://phabricator.services.mozilla.com/D36138
--HG--
extra : moz-landing-system : lando
Also, make the assertion shorter & more to the point. In particular,
I'm removing the note about stray whitespace, which is based on one
previous scenario that caused extra child frames; but I don't have
much confidence that potential future causes of this assertion-failure
will have that specific problem as their root cause.
Differential Revision: https://phabricator.services.mozilla.com/D28547
--HG--
extra : moz-landing-system : lando
Spec quote from https://drafts.csswg.org/css-contain/#containment-size :
"Replaced elements must be treated as having an intrinsic width and height of 0"
To achieve that, we just need to:
(a) make all of these frame classes' GetPrefISize and GetMinISize methods return 0 if they're styled with contain:size.
(b) make all of these frame classes' GetIntrinsicSize() and GetIntrinsicRatio() methods return 0,0.
In some cases, these methods are implemented in terms of common helper methods
(and sometimes member variables). For those cases, this patch adjusts the
helper methods (and variables) rather than the getters themselves.
Also: in one case (nsHTMLCanvasFrame), I needed to update its ComputeSize
method to remove a dependency on the "real" intrinsic size & ratio. I believe
the other classes' ComputeSize implementations do the right thing automatically
by sharing code & data with their intrinsic-size codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D28159
--HG--
rename : testing/web-platform/tests/media/white.webm => testing/web-platform/tests/css/css-contain/support/white.webm
extra : moz-landing-system : lando
This patch shouldn't affect behavior; it's just simplifying existing code with
a new convenience constructor.
Differential Revision: https://phabricator.services.mozilla.com/D28918
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
- We need nsIContentInlines.h to provide the (inline) nsIContent::GetShadowRoot definition.
- We need ShadowRoot.h to allow dereferencing of the pointer that GetShadowRoot() returns.
Differential Revision: https://phabricator.services.mozilla.com/D5564
--HG--
extra : moz-landing-system : lando
This crash happens because nsVideoFrame didn't know what to do with two
children in the UA Widget Shadow Root.
The two children are both videocontrols, with the first one being the lingering
DOM inserted by first constructor call that throws.
The subsequent appendChild of the same element caused the videocontrols
to be initialized again, since the previous run didn't return a widget
instance to UAWidgetsChild.
The fix here removes the throw statement added in
https://hg.mozilla.org/mozilla-central/rev/dca187f7c72c#l3.15 ,
allowing the constructor to complete.
Without this statement, we will rely on assertion in the test here
https://hg.mozilla.org/mozilla-central/rev/4ddca5eb06c2#l2.18
to fail on slower platforms to ensure the stylesheet is loaded synchronously.
An alternative fix would be to wrap up the contructor in a try catch block
from UAWidgetsChild and make sure the DOM is cleaned up when the constructor
throw. That however will hide the error thrown so I decided to remove the throw
statement instead.
Differential Revision: https://phabricator.services.mozilla.com/D3560
--HG--
extra : moz-landing-system : lando
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
This prevents XBL binding from being attached, and create the Shadow Root to
host controls to be created by the script.
Shadow Root and the JS controls are lazily constructed when the controls
attribute is set.
Set nsVideoFrame as dynamic-leaf so it will ignore content child frames when
the controls are XBL anonymous content, and handles child frames from controls
in the Shadow DOM. The content nodes are still ignored since there is no
<slot>s in our Shadow DOM.
MozReview-Commit-ID: 3hk41iMa07n
--HG--
extra : rebase_source : f6f8a3facc9d83f5626cf5f3b4e3fa27438a8a8f
With all videocontrols UIs implemented in HTML, there is no need to handle
XUL content in videocontrols.
MozReview-Commit-ID: Jq3SecscssO
--HG--
extra : rebase_source : 2f928a221919e7f66f9392d6dac6cf971b75776b
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
L. David Baron
alwu
Ting-Yu Lin
Miko Mynttinen
Emilio Cobos Álvarez
Daniel Holbert
Markus Stange
Masayuki Nakano
Matt Woodrow
Cosmin Sabou
Timothy Guan-tin Chien
Doug Thayer
Timothy Nikkel
Cameron McCormack
Sylvestre Ledru
Zhang Junzhi
sotaro
Chris Peterson
Andrew Osmond
Dorel Luca
Kyle Machulis
Alexis Beingessner
Boris Zbarsky
Mats Palmgren