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
What you see first is the removal of the line `this._highlightAll = aHighlight;`, which is repeated in the `_setHighlightAll` method.
This line was put here initially to make the test_findbar_events.xul test pass but in fact makes it so that the pref is never set in `_setHighlightAll`!
In other words, we never actually persisted the 'Highlight All' state properly.
Reading further: the `_dispatchFindEvent` attaches some findbar state flags to the event details, including the value of `_highlightAll`.
Even though none of our consumers use it currently (haven't checked if TB does, though), you can cancel further execution of highlighting all ranges.
Since the `_setHighlightAll` doesn't do that kind of processing, but merely makes sure the internal state is up to snuff, is persisted properly and the buttons are updated, I moved it up to be invoked before dispatching the event.
MozReview-Commit-ID: 4BBy4FR1r5c
--HG--
extra : rebase_source : 204e77aaef3cd55886daeb2e0fdef84da1159c68
Patch by Michael Wright and Freddy (Junshan) Luo.
MozReview-Commit-ID: G0CaZplABpC
--HG--
extra : rebase_source : d0e29ecc80835bf227f623643518ec0cf2d01364
Currently, <scrollbox>.lineScrollAmount returns its font height. However, according to the other methods, <scrollbox> is designed for scrolling elements in it. Additionally, old implementation declared that1 line is 1 element. Therefore, this patch makes it returns avarage width or height of the children.
MozReview-Commit-ID: E9qfhHy5sTt
--HG--
extra : rebase_source : a85c632242e5824596e9363c80323f1c9a89b39a
<scrollbox> should scroll its contents smoothly even if wheel device doesn't support high resolution scroll.
This patch makes the wheel event handler use |_smoothScrollByPixels| when deltaMode is DOM_DELTA_LINE or DOM_DELTA_PAGE. The reason why ignoring DOM_DELTA_PIXEL is, such devices are typically supports high resolution scroll. Therefore, <scrollbox> doesn't need to animate its scroll by itself.
However, |_smoothScrollByPixels| doesn't work fine without some additional fixes.
First, this patch doesn't stop pending scroll from |_smoothScrollByPixels| because discarding some pending scroll causes slower scroll. Actually, when you turn mouse wheel faster, scroll amount becomes smaller without this fix.
Next, this patch adds continous scroll mode to |_scrollAnim| object. If it's requested new animation during processing previous scroll, it keeps previous scroll amount and restart animation with new destination. Additionally, accumulating the scroll distance as fractional value. Therefore, it scrolls 3px when 1.5px scroll is requested twice.
Finally, this patch discards pending scrolls when user tries to scroll to reverse direction. When user tries to scroll to reserse direction, the user must want to scroll the contents from current position rather than actual scroll destination. Therefore, this patch discards pending scrolls in |_smoothScrollByPixels|. Although, it might be better to handle this in |_scrollAnim|. However, |_isScrolling| is not managed by it and changing the behavior in private method is safer than changing utility object (i.e., |_scrollAnim|).
Additionally, this patch fixes timestamp issue at callback of requestAnimationFrame(). Sometimes, the given timestamp is older than start time. In that case, current code scrolls to reverse diretion. Therefore, we should treat such old timestamp as same as start time.
MozReview-Commit-ID: DluWUN2VhVw
--HG--
extra : rebase_source : 067467444c7a0aee4d551410c50de3a8a97601c5
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
Similar to the previous patch, "wheel" event should use |.scrollByPixels()| instead of |.scrollByPages()| because |.scrollByPages()| doesn't support high resolution delta value.
This patch makes the "wheel" event handler of <scrollbox> use |.scrollByPixels()| at handling "wheel" events whose deltaMode is DOM_DELTA_PAGE and multiplies the delta value and |.scrollClientSize|.
MozReview-Commit-ID: 1nyD7niiq3W
--HG--
extra : rebase_source : 41265adb74c015be88bd35d7cdc3cd18a585cf84
Currently, ths "wheel" event handler of <scrollbox> uses |.scrollByIndex()|. However, it scrolls too fast when "wheel" event has high resolution delta value when its deltaMode is DOM_DELTA_LINE.
For respecting the delta value, it should use |.scrollByPixels()|. Therefore, this patch implements new readonly property, |.lineScrollAmount|, which returns font size of the |.scrollbox| and makes "wheel" event handler multiplies the delta value and |.lineScrollAmount|.
MozReview-Commit-ID: KzIvJyxqrn5
--HG--
extra : rebase_source : 0e11608bf4c47cd7aeef3c1a91b705cfcdf281ab
This adds a single flag, SWAP_KEEP_PERMANENT_KEY, which tells the
browser that when it performs the swap, the permanent key should stick
with the browser, rather than following the frameLoader.
This patch also adds the implementation of tabbrowser.swapBrowsers,
which was previously absent, despite being referenced.
MozReview-Commit-ID: CLwJYzpY8Pp
We need to notify tabbrowser about media-blocking so that we can show the unblocking tab icon.
See bug1308399 for more UX details.
MozReview-Commit-ID: E25lEhZLCZk
--HG--
extra : rebase_source : dcb6cb520bb0983010dfcc728f7251994a886612
Unreachable code can be a sign of a mistake so we should turn this rule on.
MozReview-Commit-ID: LQphsNL7HBX
--HG--
extra : rebase_source : eb5fdb1157cac6e447492ac89bb15d83dc32eef6