Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
In ancient degisn, we would only register audio channel after the media element has audio track and enoguh data to playback,
that is because the "audio-playback" event would be dispatched with the registration, and then shows the tab audio indicator.
However, now the event dispatching doesn't follow with the registration, it would be triggered when the media element has
really audible data which would be notified from media decoder.
Therefore, the media element without audio track or without enough data can also register audio channel agent, it won't affect
the display of tab audio indicator. The reason we need to do that is for blocking autoplay media in the non-visited tab.
The autoplay can be adding "autoplay" keyword or playing by the script, and we don't want to dispatch dom event for blocked
media. Therefore, we should register audio channel agent to know whether it needs to be blocked immediately even the media
element doesn't have any enough data which can let us to distinguish it have any audio track or not (this information can
be known from metadata).
First, we must check whether the media is blocked which is notified by audio channel agent, and then we can decide whether
need to dispatch the event. If we don't register audio channel agent, that we can't get blocking information.
MozReview-Commit-ID: HLLkOuecql1
--HG--
extra : rebase_source : 99c34f0185276ecd5b70ae09959b47c584d1564e
If the media was blocked, we would postpone the dom event and dispatch them after media is resumed.
MozReview-Commit-ID: LcdJtH16qQn
--HG--
extra : rebase_source : 209d18925a88a9e0dac82f2c0695ec1b60f54f63
The spec recently changed to match browsers better. There's currently
not much interop in exact details of how this work. This brings us in
line with the spec except for the limit of 1000 on the span attribute.
The added textarea failures are spurious, because I'm not updating our
local tests in this commit. The new tests are submitted upstream at
<https://github.com/w3c/web-platform-tests/pull/3518>.
MozReview-Commit-ID: 1L8aUtF47Qi
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
This prepares HTMLMediaElement for having a separate MediaStreamTrackSource for
MediaStreams, StreamCaptureTrackSource.
MozReview-Commit-ID: FVrYxFgvXgA
--HG--
extra : rebase_source : 5c162a0e861fa693fea0ba6b94b8e45446c0c13c
extra : source : a9151ac77a81573b8dbd9fee9c8aa09ba8dc7812
On Linux x64 PGO try, HTMLMediaElement was reliably invoking
decoder->NotifyOwnerActivityChanged() after SetVisible(false) was
called. This caused the pending suspend to be cancelled and the test
waits for an event that never arrives.
Fixed by adding 'forced hidden' to MediaDecoder that overrides the
element visibility that comes from HTMLMediaElement.
MozReview-Commit-ID: 5aRhxxZ5cZd
--HG--
extra : rebase_source : 5a4e1c44ddd2265eab545f8fe19c4ae47cebf7bf
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
Previously we supported insertParagraph as a synonym for formatBlock
"p", which is both useless and incompatible with all other browsers.
Edge's behavior doesn't look useful and looks redundant with insertHTML
(although it matches the name nicely, probably because they invented
the command). Blink/WebKit treat it the same as hitting Enter, which is
useful for cross-browser testing until we get synthesizeKey() in wpt.
At the same time, I added insertLineBreak, which Blink/WebKit support
with the same functionality as pressing Shift-Enter.
The new event.html failures are spurious -- we used to pass by mistake
because we didn't support insertlinebreak at all. insertlinebreak.html
has only new passes, no new failures, although it's not clear on the
diff.
MozReview-Commit-ID: 16oPcxXwGcj
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
We will now record '0' in VIDEO_INTER_KEYFRAME_MAX_MS when only one keyframe is
found when playing a video (played for at least enough time to be eligible for
video-decode-suspend feature.)
MozReview-Commit-ID: ALDmSYxs2f1
--HG--
extra : rebase_source : 70b19e9c5c976f764a744dc4bf7a0760e80dd834
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
--HG--
extra : rebase_source : f82426e7584d0d5cddf7c2524356f0f318fbea7d
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
This misspelling was introduced in bug 1125767, changeset b9951cca6d1f.
MozReview-Commit-ID: KQNlLelY2Kn
--HG--
extra : rebase_source : 7b2b8379da23b06737b462dd4c316b5758d807a9
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : 151e1f1383ab5c445eb8c957be8363340cdc4ab1
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : c4063d7c39b56e62e4f397bc21ef889ed14307c8
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 : rebase_source : 3e4e0b60493397e61283aa1d7fd93d7c197dec29
extra : source : d43c2d5e87f31ff47d7f3ada66c3f5f27cef84a9
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : transplant_source : %3D%AA%00%CE%A3SV5%8F%84%96%AC%E2%D9%10%EC%85%07N%DF
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %008z%D8W%EE%87%8E%E9/%2CT%26%EBvo%AE%099%A6
AFAICT this doesn't change behavior, since all the callers of GetRootNode should
occur after we've already called BindToFrame. However, it makes it easier for
future static analysis to see that we don't trigger node creation from
nsTextControlFrame::AppendAnonymousContentTo.
Carsten "Tomcat" Book
Stone Shih
Jean-Yves Avenard
kaku@mozilla.com
Kaku Kuo
Timothy Nikkel
Kevin Chan
J. Ryan Stinnett
Shing Lyu
Manish Goregaokar
Jessica Jong
Wes Kocher
Andreas Pehrson
Boris Zbarsky
Michael Layzell
Jeremy Chen
Phil Ringnalda
Gerald Squelart
Alastor Wu
Cameron McCormack
Edgar Chen
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Sebastian Hengst
Lee Salzman
Aryeh Gregor
Chris Pearce
bechen
Thomas Wisniewski
Ehsan Akhgari
Olli Pettay
Dan Glastonbury
Bryce Van Dyk
Decky Coss
Nicholas Nethercote
John Dai
Bobby Holley
Jonathan Chan
Gregory Szorc
Daisuke Akatsuka
L. David Baron
Ben Tian
Ting-Yu Lin
JW Wang
Iris Hsiao
Markus Stange
Yoshi Huang
ctai
Kearwood (Kip) Gilbert
Dragana Damjanovic
Andrea Marchesini