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
test_mousescroll.xul becomes permanent orange due to the animation at handling wheel event. Therefore, this patch rewrites it with generators.
Note that this removes |delta(X|Y) == 0| cases from testArrowScrollbox() because it doesn't cause wheel events, therefore, it's impossible to test without timer and it's not worthwhile to test the cases that no wheel events are fired.
Additionally, this adds todo to testArrowScrollBox() because |scrollPosition += px| in <scrollbox>.scrollByPixels doesn't work fine only on macOS with this test. Even when the px is larger than its scrollSize, the result isn't set to scrollSize. This issue shouldn't be the scope of bug 1320609, therefore, this patch makes it todo. (Of course, I don't see any problem with actual UI such as tabbar and bookmark menus.)
MozReview-Commit-ID: AmAf1YmgkBn
--HG--
extra : rebase_source : 7462845098d35da4c952048738e570a8a915b36a
<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
Bug 1321418 - 1. Use GekcoBundle events in GeckoApp; r=snorp r=sebastian
Switch GeckoApp to using GeckoBundle events everywhere. UI or Gecko
events are used if the event requires the UI or Gecko thread,
respectively, and background events are used for all other events.
There are changes to some other Java classes, such as SnackbarBuilder
and GeckoAccessibility, due to the switch to GeckoBundle.
For "Snackbar:Show", we need the global EventDispatcher because the
event can be sent to both GeckoApp and GeckoPreferences. Howveer, we
only want one listener registered at the same time, so we register and
unregister in GeckoApp's and GeckoPreferences's onPause and onResume
methods.
Bug 1321418 - 2. Use appropriate JS EventDispatcher to send GeckoApp events; r=snorp r=sebastian
Change JS code that sends events to GeckoApp to use either the global
EventDispatcher or the per-window EventDispatcher.
"Session:StatePurged" is not used so it's removed. "Gecko:Ready" in
geckoview.js is not necessary because it's only used for GeckoApp, so
it's removed from geckoview.js.
Bug 1321418 - 3. Use GeckoBundle events in BrowserApp; r=snorp r=sebastian
Switch BrowserApp to using GeckoBundle events, in a similar vein as
GeckoApp. UI or Gecko events are used if the event handlers required UI
or Gecko thread, respectively, and background events are used for all
other events.
Some other Java classes also have to be modified as a result of
switching to GeckoBundle.
Bug 1321418 - 4. Use global EventDispatcher to send BrowserApp events; r=snorp r=sebastian
Change JS code that sends events to BrowserApp to use the global
EventDispatcher instead of "Messaging".
Bug 1321418 - 5. Update usages of events in tests; r=gbrown
Update cases where we use or wait for events in tests.
Wes Kocher
Ryan Hunt
Masayuki Nakano
Michael Layzell
Phil Ringnalda
malayaleecoder
Jessica Jong
lochang
Ray Lin
Gabriele Svelto
Carsten "Tomcat" Book
Jared Wein
Ryan Kelly
Scott Wu
Gijs Kruitbosch
Matheus Longaray
Joel Maher
Marco Bonardo
Mark Banner
Michael Froman
Tomer Cohen
Jim Chen
Neil Deakin
Cameron McCormack
Tooru Fujisawa
Timothy Guan-tin Chien