Removed test blocking execution of ReportTelemetry in non-MSE case.
EME currently depends on MSE, so ReportEMETelemetry won't do anything in the
non-MSE case anyway. But I think it's good to remove the MSE test as well, in
case we change that limitation in the future.
MozReview-Commit-ID: 8sTg5F13KMs
--HG--
extra : rebase_source : f4acd3011f34be11b37c221ffd8439f6396fd37d
These numbers are only used to calculate a percentage, so they don't really
need to be 64-bit long.
MozReview-Commit-ID: FfdyStjGITL
--HG--
extra : rebase_source : 704d7664a3462f68f2c495e3b5d66f71180d290b
VideoPlaybackQuality was fed uint64_t's, now it should be given uint32_t's.
Note that FrameStatistics currently provide uint32_t's, so we are fine now;
nevertheless I added a static_assert to verify that and ensure it stays true.
MozReview-Commit-ID: I0dgP1K4lg3
--HG--
extra : rebase_source : f8d673db0cd45d2b3ae03c092dff217e5d7ebbee
Note that this is a simple duration counter based on the existing (non-hidden)
play-time, but it only counts when video is playing while hidden.
There is no bucketing yet, future probes may add finer-grained information.
MozReview-Commit-ID: DUfryXjGBAN
--HG--
extra : rebase_source : 4d0bd7f60329dba6c6a6ab039cc733315c50b686
This is so that if media autoplay is disabled, a site can capture user intent
to play in their click handlers by calling load() on an empty video element to
"bless" the video element with the ability to play later when the video has
loaded.
Large video sites typically have a catalog view of videos to chose from on
their main page, and when the user clicks on one, with this patch, the site can
bless a video element so that it will play by beginning the load of that video
in the click handler. Often these sites do a bunch of asynchronous things
before they actually get around to playing the video, they don't call play in
the click handler, so we need another way to bless the videos so they can play.
We allow seeks in a click handler to capture user intent to play, so I don't
see why we should not also allow a load() to capture user intent.
MozReview-Commit-ID: KzjNcn3s6od
--HG--
extra : rebase_source : 6424e04ecb5220b765b69e815fc7b15c49ea6cb8
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : histedit_source : 5390eeebfe9a2791d9ac8e91ec1dfec4ec7b4118
Use ReconstructFrame to replace NS_STYLE_HINT_FRAMECHANGE in many places, such
as HTML*Element::GetAttributeChangeHint and HTMLFrameSetElement::SetAttr.
MozReview-Commit-ID: EHbc4RMeuu0
--HG--
extra : rebase_source : f5163608c88362595ef5af5fcd36fa64c9c79ce7
