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
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
<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
