Previous design allows us calling resume/block from both front-end and back-end,
it's not easy to know who called these operations.
So move all these logic to frond-end side, it's more clear than before.
One important thing is that we should block tab before loading the content.
If we block the tab after loading, the media might not be blocked because it had
already started (that is one situation I observed from test).
The value of block state would be stored in the outer window, before media want
to start, it would check this value to know whether it can start playing or not.
---
In addition, introduce new attribute "media-blocked".
The "media-blocked" attribute indicates that whether the tab is allowed to play autoplay media.
The "activemedia-blocked" attribute indicates whether the tab has blocked the autoplay media.
MozReview-Commit-ID: FnNh3zmItxo
--HG--
extra : rebase_source : cdc890c0c47a4a03ea8dbbdfee24c66b52945c60
This patch uses the new Photon animation curve for notification bars as well
as supporting `toolkit.cosmeticAnimations.enabled` to disable the animations
on notification bars entirely.
MozReview-Commit-ID: AHSQR32g6hf
--HG--
extra : rebase_source : 9b643a758db07791dbda12f7e6383f193f3fa698
Reset button should not be tabbable or focusable.
MozReview-Commit-ID: IboMKl3n0LY
--HG--
extra : rebase_source : 7bec15cfb601cd15a99d26e39b39446ef3ca5601
With ideas and code from Oriol <oriol-bugzilla@hotmail.com>.
MozReview-Commit-ID: CjuCAkYaort
--HG--
extra : rebase_source : dd53d1a665a5aba8ef094ee82dffe9c6c010d3d6
The APZ scrolling codepath doesn't do the right thing for <listbox>
without special handling, so have it scroll in JS instead, like we
did in bug 1302736 for <tree>.
MozReview-Commit-ID: LWJCBfhZ3Hc
--HG--
extra : rebase_source : bb8b2f7e713d35822a956e08f4e0eed0557b07b3
If we rely on XUL panel's default behavior, the picker is hidden and opened
again when we jump from one inner field to another with a mouse click, this is
because XUL pannel gets hidden when user clicks outside it with
noautohide=false. In order to avoid this, we should close it explicitly only
when input element blurs.
MozReview-Commit-ID: GxPxd0wPWgM
--HG--
extra : rebase_source : 3bac43a57da51a341d7ec4bb7b86807f55308f39
The scroll destination of the smooth scroller of <scrollbox> can be outside of the actual scrollable range. Therefore, it doesn't make scroll slower even when the end appears.
This patch makes the destination always in the scrollable range.
MozReview-Commit-ID: CfEGzhG7Jh7
--HG--
extra : rebase_source : 87a07140a1ce58752ac264a1e8decb2a8af6d078
EnsureElementIsVisible can cause a Layout flush, so we should try to avoid it when possible.
MozReview-Commit-ID: Dr0D8vPl9rd
--HG--
extra : rebase_source : e1d6de9c1449f0b4d9780d374e5632fb40498902
Set the .dir property of the input box wrapper to `rtl` if this is a RTL
locale.
MozReview-Commit-ID: D2qJVjvzxNW
--HG--
extra : rebase_source : f0514ab18fe129600adfbd695f15594c6f4c8ca9
Since the inner fields of date/time input are now <span> instead of <input>
text, we are adding an API for binding code to set the focus state of the
bound input element when inner fields are focused/blurred.
MozReview-Commit-ID: 9wvu57xT6HZ
--HG--
extra : rebase_source : c6c3832fe0aa0fe9429052dcb5b15a3497c33fa4
When adding support for RTL in date/time input box, we noticed that bidi text
was not displayed properly with mixed of inline and block elements. By
changing our editabled fields from <input> to <span>, we can rely on bidi
algorithm and markups to display the inner fields in the right order.
MozReview-Commit-ID: 7r8OVSJXJRU
--HG--
extra : rebase_source : b130a5424b533930a57695a65196454c72d7be10
We could not avoid controls being focused after De-XUL, in order
to preventDefault before event propagate to focused control, we should
change the way of keypress event propagation in media controls.
MozReview-Commit-ID: 4KNPU4XlSDJ
--HG--
extra : rebase_source : 1146e18e3beebca8ae36a4de126c5c920aa5cdfd
We used to have this rule in shared stylesheet for both mobile and
desktop, but the namespace mismatched after visual refresh (De-XUL).
Now we should add this rule back to hide cursor while fading out.
MozReview-Commit-ID: HDZKn8CrQ5X
--HG--
extra : rebase_source : 7a63650b9f048dd5b0b0b79ce289bc762cc6a07b
Add a new attribute "rawValue" in each of the numeric fields. We store the
non-formatted number in this attribute, and display formatted number using
Intl.NumberFormat.
MozReview-Commit-ID: JkcBObFoYQ3
--HG--
extra : rebase_source : 05918ba57513f9c816273a758ab2aa7198722135
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
--HG--
extra : rebase_source : 61d2aa91bf9474af3d72a5dea41b25dca442c1b7
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 513ed31d995864939aa893e73c81ffdf591a6617
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 13fa4c397ba4c79303a2cd76684b5b8c4bd17331
Undo incorrect change from bug 1341029, and tell ESLint about how Utils is 'global' to some of the videocontrols.xml event listeners.
MozReview-Commit-ID: 9ItMIzwYhEj
--HG--
extra : rebase_source : 4ea996771c00e25e7e33063cfb56cf19c2cf059a
Use entities declared in DTD files so that lozalizers can fill in appropiate
placeholders for each locale.
MozReview-Commit-ID: 9KODExaDnDe
--HG--
extra : rebase_source : e6a9f27c68907aded0483028aee3a17744491a56
The DOMAudioPlaybackStarted event would affect the tabbrowser's attribute,
"soundPlaying", and this attribute should indicate whether the tab is audible or not. However, in present codebase, even the tab has "soundplaying", it doens't mean
the tab has audible sound, you need to check extra attribute, "muted".
After applying this patch, tabbrowser can only own one of the attributes ("soundplaying"
or "mute"). These attributes won't exist at the same time, so we can easily know
whether the tab is audible by checking "soundPlaying".
Let's see an example,
step1. playing a playing audio
- tab owns "soundPlaying"
step2. mute the tab
- tab owns "muted"
step3. stop audio
- tab owns "muted"
step4. replay the audio
- tab owns "muted"
step5. unmute the tab
- tab owns "soundPlaying"
step6. stop audio
- tab owns ""
MozReview-Commit-ID: EEKEbAVzsVm
--HG--
extra : rebase_source : 823d501e9162ae8b611f2e97dd763c1eec16c2cf
The DOMAudioPlaybackStarted event would affect the tabbrowser's attribute,
"soundPlaying", and this attribute should indicate whether the tab is audible or not. However, in present codebase, even the tab has "soundplaying", it doens't mean
the tab has audible sound, you need to check extra attribute, "muted".
After applying this patch, tabbrowser can only own one of the attributes ("soundplaying"
or "mute"). These attributes won't exist at the same time, so we can easily know
whether the tab is audible by checking "soundPlaying".
Let's see an example,
step1. playing a playing audio
- tab owns "soundPlaying"
step2. mute the tab
- tab owns "muted"
step3. stop audio
- tab owns "muted"
step4. replay the audio
- tab owns "muted"
step5. unmute the tab
- tab owns "soundPlaying"
step6. stop audio
- tab owns ""
MozReview-Commit-ID: 50NorRbRIP
--HG--
extra : rebase_source : 8a06d1df7f4e3b974b18292944b19ada20eb655d
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
This changes the `relatedBrowser` property which held a <xul:browser> to the
more explicit `sameProcessAsFrameLoader` which takes an nsIFrameLoader.
This clarifies the purpose of the property and also (by switching to the frame
loader) makes it easier to set in some contexts.
MozReview-Commit-ID: LnEvSP8zkto
--HG--
extra : rebase_source : f9f4c07995ef39f1ccd5042e9ae3df37879423b6
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
--HG--
extra : rebase_source : b5f8855b17664bb1cc2b485f1d85120c0939931f
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
--HG--
extra : rebase_source : 7b4214f1f552ba75da94e4bb1795178983af20f7