So that the we can listen to the 'canplay' event in the videocontrols.xml.
MozReview-Commit-ID: 5T7akeC7EJq
--HG--
extra : rebase_source : c9f932e021fc7939dc8558813a1a974753a968ec
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
Now that nsLiteralStrings are "free", they can just be static globals.
MozReview-Commit-ID: 4d4ZObxiHF8
--HG--
extra : rebase_source : 184e8a41b959550df217732cb4c605b302e2a1ac
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
These would fail to compile once nsTLiteralString stops inheriting from nsTString.
MozReview-Commit-ID: DFvuESN8G5s
--HG--
extra : rebase_source : 14f4ea7b59d14786949a2d57c40f4e740b1aa34a
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
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
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.
If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.
For consistency with the other browsers, this patch doesn't move focus to other focusable element.
MozReview-Commit-ID: 6sNsuzwqECX
--HG--
extra : rebase_source : 9ba52ab0bd1249abded81019847c85182ca1926e
Selection needs to be able to distinguish if every selection change is caused by JS (i.e., via Selection API) or the others.
This patch maps some methods of Range and Selection to *JS(). Each of them marks its instance as "used by JS" and calls corresponding method.
With this change, Selection::NotifySelectionListeners() can move focus only when it's caused by Selection API.
MozReview-Commit-ID: 1GoLHiIJ10Y
--HG--
extra : rebase_source : 02d497f9e55b3325a2e01c3041cadb90881dccb8
Adding automated tests as web platform tests (only for mozilla) for focus move at using Selection API.
Although, there is no standards of relation between Selection API and focus, we should move focus when Selection API moves selections into only an editing host or outside of focused editing host.
Chrome moves focus as this rules, therefore, user can modify contenteditable editor immediately after web app moves selection.
Edge does NOT move focus at using Selection API. However, user can modify contenteditable editor similar to Chrome. We can guess that Edge doesn't need to move focus in its design because perhaps, Edge decides if it's editable only with primary selected range.
We cannot take the Edge behavior due to our editor design. So, we can take only Chrome's approach for improving the compatibility.
MozReview-Commit-ID: JuLiSMgqODm
--HG--
extra : rebase_source : 4cd77194faed00d46b95dcf59151b2492a135675
Edited all function calls in KeyFrameEffectReadOnly.cpp and one function call in EffectCompositor.cpp
MozReview-Commit-ID: BzSHLZna4xX
--HG--
extra : rebase_source : ee5a8196ce73e67308974b7fb5be19f61982320b
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
Now that nsLiteralStrings are "free", they can just be static globals.
MozReview-Commit-ID: 4d4ZObxiHF8
--HG--
extra : rebase_source : 184e8a41b959550df217732cb4c605b302e2a1ac
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
These would fail to compile once nsTLiteralString stops inheriting from nsTString.
MozReview-Commit-ID: DFvuESN8G5s
--HG--
extra : rebase_source : 14f4ea7b59d14786949a2d57c40f4e740b1aa34a
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
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
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
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
If mHasSuspendTaint is set, the mVideoDecodeSuspendTimer should already be canceled
so that HandleVideoSuspendTimeout() won't be invoked.
MozReview-Commit-ID: BGwSucZtH4d
--HG--
extra : rebase_source : a7038309846365cb3905aa193b25d103812a9200
extra : source : 28ca96e1622d7f3af427c90f7b4a2bbc58b81ce8
The role of MDSM::mIsVisible and MDSM::VisibilityChanged() have been replaced by
the MDSM::mVideoDecodeMode and MDSM::VideoDecodeModeChanged() completely.
MozReview-Commit-ID: 8sW0s8ilF1E
--HG--
extra : rebase_source : 20f4b0c2e5a34018b3189b4d10dd55e68881c0e7
extra : source : 2eba9a76da70749583125176e8b7c6c959b74d38
So, the MediaDecoder is the one who rules out the policy of suspending video decoder.
We also extract all the policy rules into one single method, MediaDecoder::UpdateVideoDecodeMode().
MozReview-Commit-ID: IOQq6kFfkIs
--HG--
extra : rebase_source : 3d92c63aed2545391c45cdd7c1236d5df0b8d2f8
extra : source : 9c6c5f22d25171a206e828faa2c7c91d47f748f1
The MDSM::mVideoDecodeMode and MDSM::SetVideoDecodeMode() are merely a renaming of MDSM::mIsVisible and MDSM::VisibilityChanged().
However, the renaming explicitly reflects that MDSM provides mechanism only without participating in the policy decision.
Will reremove the MDSM::mIsVisible and MDSM::VisibilityChanged() in following patches.
MozReview-Commit-ID: JdMKQTgVCf3
--HG--
extra : rebase_source : 95977b205f235b6a456d12dfde93fe84f3b12aa7
extra : source : 4382a3c10f30653d5a70abb3bd4b8146a4272784
Kaku Kuo
Matthew Wein
Tomislav Jovanovic
Xidorn Quan
David Major
Nico Grunbaum
Masayuki Nakano
BharatR123
Iris Hsiao
Blake Kaplan