This will make the timing of the change more consistent between SetAttr and
UnsetAttr, and ensure that we have both the old and new type available in
AfterSetAttr.
MozReview-Commit-ID: Gsrxkkve7BC
The UpdateState calls in BeforeSetAttr were there in case an AttributeWillChange
observer examined the element state and expected it to be updated to whatever
changes BeforeSetAttr made. But at this point, AttributeWillChange runs before
BeforeSetAttr, and there is no code that runs between BeforeSetAttr and the
subsequent UpdateState in SetAttrAndNotify/UnsetAttr that cares or could care
about the state of the element. So it's safe to do no state updates in
BeforeSetAttr and just do the single UpdateState we already do.
MozReview-Commit-ID: BQOPVgHyC0H
This removes the requirement that BeforeSetAttr comes before AttributeWillChange
(which needs the preparsed new value).
MozReview-Commit-ID: 87C6Mjc7ARh
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
We never suspend videos that is NOT in-tree because we found that, according to the Telemetry data, most (>70%) videos
which are used as the argument of drawImage() are not in-tree. So, by preventing suspending not-in-tree videos, we should
be able to alleviate the pain of not able to resume video decoders synchronously.
MozReview-Commit-ID: 8eqs0pHZLIt
--HG--
extra : rebase_source : 964c0047753696cad2e40bcf74c2b8ee9faccdea
extra : source : 93c38caa15b1a29f8f1e8e6d3a5e859f97bc1aae
Initialize the MediaDecoder::mIsElementVisible to be "!aOwner->IsHidden()" at the MediaDecoder's constructor is wrong.
Insted, we initialize both MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible to be false at the construtor,
and then assign the HTMLMediaElement's real values to them at HTMLMediaElement::FinishDecoderSetup() via the the MediaDecoder::SetActiviyChangesToDecoder().
The initialization values of MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible (in the constructor) do not matter because the valuse are
not read untile the first MediaDecoder::SetActiviyChangesToDecoder() method call.
MozReview-Commit-ID: Cdovq5pG9Nv
--HG--
extra : rebase_source : 91f3b4c2515124b4c195dd246bd9b404178a35de
extra : source : 81b5e89a5bd20f37b8c3daa1230db30808026ff4
Make HTMLMediaElement no longer has logic of deciding visibility, it just passes all information into MediaDecoder.
MozReview-Commit-ID: ApVcEQfboO
--HG--
extra : rebase_source : 88c70b0cf1933d9cf814359909463a811be2ab9f
extra : source : 669d1340d3c93d3e0eab55ce87693f842cf40247
Move all the policy rules into this method now, will then move the policies into MediaDecoder at next patch.
MozReview-Commit-ID: ILAYLrTwCJy
--HG--
extra : rebase_source : 8ae3adcbbd8f2fd61f0da0de437f41f78d945c89
extra : source : feb8ad754e86b43e15bf2eeb3a2ba2dc24a00599
MDSM's dormant mechanism has nothing to do with the HTMLMediaElement's states now.
MozReview-Commit-ID: 4RSHsexy7fi
--HG--
extra : rebase_source : cb84fda2c182c63c6276b143ce071afc01c694d8
extra : source : af0217686959affe143167487588faab137212ce
These prefs have been added close to two years ago:
dom.url.encode_decode_hash and dom.url.getters_decode_hash
The main reason for their existence was in case we encounter any web-compat issues. At this point the extra code is mostly useless, and flipping the pref may lead to crashes.
MozReview-Commit-ID: LhAHkYmv0TR
--HG--
extra : rebase_source : 8f2d50d5633496cf165b3925d952bb6475bce3e0
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
--HG--
extra : rebase_source : 79e1bbdc671abb8555d68f7fb6106929c45fd528
extra : intermediate-source : 47fbcedbed69a5434b1cb25b8f72f862e9cefeac
extra : source : 149234329b62015dfd2e954030c23bf9c6b1d55e
This introduces two behavior changes:
1) In cached mode, we used to treat unknown selection directions as "none".
Now we treat it like "forward", consistently with the "have an editor" mode.
2) Before this change, in cached mode, we did not fire "select" events on
selectionDirection changes.
MozReview-Commit-ID: 4nBCAm3mAiz
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionEnd changes.
3) Changes the IDL type of HTMLInputElement's selectionEnd attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: J3Gkhr8VnbS
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionStart changes.
3) Changes the IDL type of HTMLInputElement's selectionStart attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: JM9XXMMPUHM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
MozReview-Commit-ID: AEW9D1zG6sM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
In particular this ensures that our ValueChanged() is correctly set to false
when we call SetValue() on our editor state with our default value. We will be
relying on this very shortly.
MozReview-Commit-ID: AIIIHwfQPQE
If the media starts after muting the tab, IsOwnerAudible() would always return
"eNotAudible". It causes that the "play tab" icon can't be displayed because we
only show the "play tab" icon for the "eMaybeAudible" or "eAudible".
We should check whether owner owns the audio track to decide the return value.
MozReview-Commit-ID: DGwkArx0a4R
--HG--
extra : rebase_source : 920968acc744593f4ef383be4068352233c74101
In bug1319771, we found that the tab would become visible unexpectly in short
period in some situations. We don't want to resume the tab in this kind of
situation, so we check whether there is any alive media component in the tab
using IsServiceStarted(). However, since we have lots different ways to create
the service, this function is not accurate at all.
Therefore, we can add media element directly to the document when it binds to
tree so that we can really know whether there is any alive media component.
MozReview-Commit-ID: FvZFg91IqgE
--HG--
extra : rebase_source : 43c2460f6e9a39d44bf2ca1638c992a0e27b196c
At this point, all this method does is ensure editor initialization and then ask
the editor state for various information. Let's cut out the middleman.
MozReview-Commit-ID: p491umScJO
Similar to DecodeError, except we allow decoding to continue.
MozReview-Commit-ID: FN9m03o6GXV
--HG--
extra : rebase_source : a6ca0cc28d2990ab143676758cd880baaca7bcb7
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
If we don't have any alive track in MediaTrackList, we don't need to mute
MediaElement.
MozReview-Commit-ID: 9vY692O7N0e
--HG--
extra : rebase_source : 3abd2fb360385b1975dbffd9dcaf4e395b1afda1
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
--HG--
extra : rebase_source : ad2985bd14d6a9b91a73c0d4103aa51c4981124c
This is a terrible hack, asking input[type=range] in our video control
xbl binding content continue to handle mouse/touch event, even if the
event is being defaultPrevented by the content.
MozReview-Commit-ID: G1huxbS7oeq
--HG--
extra : rebase_source : 27153ce36e6883d947894da69dd9aca47965e99b
