This is the bulk of the changes.
- DisplayItemScrollClip is removed. Instead, we will have 1) ActiveScrolledRoot
and 2) DisplayItemClipChain.
- ActiveScrolledRoot points to a scroll frame and allows traversing up the
scroll frame chain.
- DisplayItemClipChain is a linked list of clips, each clip being associated
with the ActiveScrolledRoot that moves this clip.
- Each display item has an ActiveScrolledRoot and a clip chain.
- nsDisplayItem::GetClip returns the item of the clip chain that scrolls with
the item's ASR. The separation between "regular clip" and "scroll clips"
mostly goes away.
- Tracking clips in the display list builder's clip state happens very
similarly to how regular clips used to be tracked - there's a clip chain for
content descendants and a clip chain for containing block descendants. These
clip chains are intersected to create the combined clip chain.
- There are strict rules for the ASR of a container item: A container item's
ASR should be the innermost ASR which the item has finite clipped bounds with
respect to.
- At some point in the future, ASRs and AGRs should be reunified, but I haven't
done that yet, because I needed to limit the scope of the change.
MozReview-Commit-ID: KYEpWY7qgf2
--HG--
extra : rebase_source : c727f6300a35463750639e165bfa37374c06b851
During the refactoring of nsSliderFrame::SetCurrentPositionInternal in Bug 957445, one
of the two calls to nsSliderFrame::UpdateAttribute was missed. This resulted in the position,
identified with nsGkAtoms::curpos, not being updated immediately after the call to
nsSliderFrame::SetCurrentThumbPosition
MozReview-Commit-ID: 6gedouG4OFX
--HG--
extra : rebase_source : dd29d90e6f10be87f652241ad138d4533bda1010
Delete the "or 0 for no movement in that direction" from the CanAdjustEdges
document in nsMenuPopupFrame.h because the only caller in nsResizerFrame.cpp
never passes 0 to it.
MozReview-Commit-ID: 3A5A8O4MDn1
--HG--
extra : rebase_source : 3a961f9195d7887f8abb5c31ae9ec088f78a2626
We aren't likely to implement predictive size decoding for XUL images. So instead do some sync decoding when we Draw them at their specified size. This will avoid a paint where we don't draw the image, or draw it at the wrong size, followed later by the correctly sized image.
Original patch by Tyler Maklebust <tmaklebust@gmail.com> and Jared Beach <beachjar@msu.edu>
MozReview-Commit-ID: 7FW6PHIrXF4
--HG--
extra : rebase_source : e8132fc8af91657ca80f18a841101bc1070c8b15
In cases where a mouse click that starts a scrollbar drag is also what
layerizes the scroll frame, the StartAsyncScrollbarDrag message needs to
arrive after the layer transaction. This patch ensures it does.
MozReview-Commit-ID: A02qRb6yWxg
--HG--
extra : rebase_source : 3517e8c8a578a0bd257a80bb8cb81303d171bb6c
This patch makes nsMenuBarListener clear its accesskey state when it receives a "deactivate" event of its top level window and reverts the change of nsMenuBarListener::Blur() by bug 625151.
"blur" event may be caused by focus move in the contents after "mosuedown" event. Therefore, mAccessKeyDownCanceled may be cleared unexpectedly. Listening to "deactive" event keeps bug 625151's fix because it's a bug after deactivating the window with Alt+Tab.
MozReview-Commit-ID: 4mAmXpxmDdv
--HG--
extra : rebase_source : 1bd9299a37bc5a1feccb61ba6c3db6b389560ec0
Let's move the code adding/removing event listers to nsMenuBarListener because it makes what we maintain them easier.
This patch makes nsMenuBarListener store event target which is composed document node of the menubar content as a weak reference but this must be safe because when nsMenuBarFrame (stored as mMenuBarFrame) is being destroyed, OnDestroyMenuBarFrame() which clears the storing event target reference is always called. We should be able to assume that the content and its composed document has never gone before destroying its frame...
MozReview-Commit-ID: DdOtRzUAL1Z
--HG--
extra : rebase_source : bfc337aaad447ad4a9d78b2f3a9e49c72db1498e
test_scroll_snapping_scrollbars.html is failing when apz.drag.enabled
is true because synthesizeMouse does not route events through APZ,
meaning that the drag is never handled by APZ or Gecko.
Resolve this by adding a check that mHandledByApz flag is true for
WidgetGUIEvent, and handle in Gecko if that is not the case.
MozReview-Commit-ID: IrxVLxqs64V
--HG--
extra : rebase_source : c76e9fed3dcab806b17e85740c94339ac0e7ccca
Fix thumb position determination in these places:
- nsSliderFrame::StartAPZDrag() -- Constrain sliderTrack using
GetXULClientRect() to match dimensions used in
SetCurrentThumbPosition() and DoXULLayout(). This is what caused
the scaling/offset mismatch.
- nsSliderFrame::StartAPZDrag() -- Adjust nonsensical calculation of
cssSliderTrack. Should be sliderFrame + scrollbarFramePosition -
compositionBoundsPosition, to get coordinates relative to the same
region as that of APZ event coordinates.
- AsyncDragMetrics -- Make mScrollTrack and mScrollbarDragOffset float
instead of int coordinates.
- AsyncPanZoomController::HandleDragEvent() -- Use
GetAxisLength(scrollTrack) instead of GetAxisEnd(scrollTrack) in
calculation of scrollMax.
- AsyncPanZoomController::HandleDragEvent() -- Only change position on
MOUSE_MOVE.
Additional refactors:
- Rename HitTestingTreeNode::GetScrollSize() to GetScrollThumbLength(),
along with related functions/variables.
- Rename AsyncPanZoomController::GetAxisSize() to GetAxisLength().
- Rename cf to scrollFrame in nsSliderFrame::StartAPZDrag().
MozReview-Commit-ID: CIsU8Pj6qfa
--HG--
extra : rebase_source : 29548fb95ec3e958d903d964753857ee949753ba
Boris Zbarsky
Markus Stange
Cameron McCormack
Florian Quèze
Wes Kocher
Gijs Kruitbosch
Kearwood Gilbert
Carsten "Tomcat" Book
Ting-Yu Lin
Phil Ringnalda
Botond Ballo
Ehsan Akhgari
Neil Deakin
Ryan VanderMeulen
Timothy Nikkel
Tyler Maklebust
Bobby Holley
Shing Lyu
cku
Iris Hsiao
Olli Pettay
Masayuki Nakano
Kevin Wern
Mats Palmgren
Marco Bonardo
Julian Seward