input.value setter removes editor flags and max-length to set value. To clean up code, I would like to use RAII class to set and restore it.
Actually, when the frame is being destroyed by InsertText, it isn't restored. But it might be safe since the flags is set again on nsTextEditorState::PrepareEditor by focus.
MozReview-Commit-ID: J0OYYluWD8z
--HG--
extra : rebase_source : b0489a381cdea76fe98f328cbd88cd18d2576a93
If the video is paused, then set the "TextTrack.mode=hidden/showing", in this case, TimeMarchesOn will return at step 7,
not update the screen. So call DispatchUpdateCueDisplay explicitly to update the screen.
MozReview-Commit-ID: IuazaeSXX31
--HG--
extra : rebase_source : fbc72c1fa9327e9719e54b63b70cbcd3be3e4069
Defer determining whether we have usable decoders to an off-main thread in
order to avoid janking the main thread.
MozReview-Commit-ID: Ape5zEBBMrz
--HG--
extra : rebase_source : 1b77046ebb7bb2d4ff1ba53afce904d3de45c335
Actually, we use GetValue to check whether value is empty or not for placeholder. But since GetValue uses TextEditor::OutputToString when on editor, it is expensive. Since editor has DocumentIsEmpty method, we should use it for this case.
MozReview-Commit-ID: rQX8yjnWQz
--HG--
extra : rebase_source : 25ec89385d704f5c4d2d0a15021c2a59b0201983
Since we don't want to show media control for media without audio track (eg. GIFV),
it's no need to register audio agent for them.
MozReview-Commit-ID: 22YrMkpNrcP
--HG--
extra : rebase_source : 78a6c41b6018f91ed9370fb2f15c650fe76ba3a1
According to the spec, content from loopback addresses should no longer
be treated as mixed content even in secure origins. See:
- 349501cdaa
- https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
Note that we only whitelist '127.0.0.1' and '::1' to match Chrome 53 and
later. See:
- 130ee686fa
It is unclear if HTTPS origins should be able to use workers and WebSocket
connections through a loopback HTTP address. They are not supported in Chrome
(whether this is intentional or not is uncertain) so lets just ignore them for
now.
See also: https://github.com/w3c/web-platform-tests/pull/5304
Should also update audio playing changed after resumed from page.
MozReview-Commit-ID: 66vuJJFeWN3
--HG--
extra : rebase_source : 06802b2e49f5e712a1d9fd34d4ae017995faaa75
Nobody uses them anymore. Therefore, we can remove them from the tree.
MozReview-Commit-ID: KTqCeI2eeFW
--HG--
extra : rebase_source : f3fc274f39c135af51245efd4c4aebbc4c49a61f
The part is mainly to set urgent-start for loading media when it's initiated by
user interaction. For the HTMLMedia element, it has its algorithm to pre-load
the media and users will get feedback once they play the media. Thus, I only
set urgent-start when the media element has autoplay attribute since the sooner
enough resource is loaded the sooner the media will be played.
MozReview-Commit-ID: 7nu3PUt8iYo
--HG--
extra : rebase_source : f1abfecdccb74f4ec79a057534c2e9a1bfd5ae41
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
maxlength will be set by nsTextControlFrame::AttributeChanged via RestyleManager. If element is display:none, RestyleManager won't call Frame's AttributeChanged. So we should always initialize maxlength when setting focus.
Also, wrap attribute for textarea element will be updated by HTMLTextAreaElement even if display:none. So this issue doesn't occur. maxlength might have to be updated by HTMLInputElement. But it is unnecessary to update editor's maxlength on display:none since this is used on focused editor.
MozReview-Commit-ID: JHODOBTv62v
--HG--
extra : rebase_source : eeabd25f6f7d2802b5a97ae8be225182c6df88de