If the current scroll position is fractional, e.g. y=N.4 CSS pixels, and something tries to read the
position in CSS pixels and scroll to that position (e.g. calling window.scrollTo(0, rootElem.scrollTop),
or equivalently window.scrollBy(0, 0)), it can actually end up scrolling backwards. So create a new
method nsIScrollableFrame::ScrollToCSSPixels which ensures that scrolling to a CSS pixel offset tries to
preserve the current fractional scroll position if that's possible, and if that's not possible at least does
not allow the scroll position to move in the wrong direction.
There was a subtle reftest failure on Mac in RTL text-overflow tests.
I tracked it down to RTL overflow:auto areas being automatically scrolled by a subpixel amount.
This was because we try to set scrollbar "curpos" attributes to an integer number of CSS pixels representing
the scroll amount, relative to the top-left of GetScrolledRect, which is a noninteger number of CSS pixels
in this case. Then in ReflowFinished() we scroll to the saved curpos values plus the top-left of GetScrolledRect.
This patch fixes the problem by making CurPosAttributeChanged pass an allowed scroll range to
ScrollToWithOrigin. We allow any scroll destination that, when rounded to CSS pixels, would give the same
value as "curpos".
This fixes the bug, ensuring that ReflowFinished's call to CurPosAttributeChanged will not normally need
to scroll because the current position will be in the acceptable range. Also, it means that code that
scrolls by setting the "curpos" attribute will be optimized to try to hit a layer pixel boundary.
--HG--
extra : rebase_source : 3a768883feee4ff2b88fe3c729ea1058e911f2ea
When asked to scroll a 1,1 appunit rectangle into view, ScrollFrameRectIntoView will now actually
succeed!
For example if the window is 6000 appunits high and we ask to scroll a 1x1 rect at 0,6000 into view,
before bug 681192 was fixed we'd actually fail to do so. We'd compute a desired scroll destination of 0,1,
and ScrollTo would round that to 0,0 and we wouldn't scroll at all.
Now, we compute a desired scroll destination of 0,1 but also an allowed scroll range for y of
"1 to <someting large>", so ScrollFrameRectIntoView will scroll down by a full pixel to 0,60. This is correct ---
it gets the subpixel area into view, which the previous code didn't --- but it's not really what DoAutoScroll
wants, at least the way test_mousecapture.xul is written. test_mousecapture.xul expects DoAutoScroll to scroll
windowheight+N into view by scrolling down by exactly N pixels, so the desired point is exactly at the bottom
edge of the window rect. Using a zero-sized rect achieves this.
--HG--
extra : rebase_source : 5d3d8cc4417c35dc88ad296a4f13e01d2c1c9233
This patch ensures that the NODE_IS_EDITABLE flag is only set on nodes living
under an editing host. Things like text controls which used to have that flag
previously will not have it any more. The flag would be set on their anonymous
div node instead. Note that if text controls actually fall under an editing
host, they will get the NODE_IS_EDITABLE flag.
This patch also makes nsHTMLEditor::IsEditable return sane results (text nodes
are always considered to be editable).
Currently we return an extra out parameter on GetOpaqueRegion. This is ugly and it's also going to be inefficient
because in a followup patch I'm going to avoid calls to GetOpaqueRegion, but we still need to know whether the item
needs a transparent surface. So this patch removes that out parameter. Instead, we rely on the fact that only
Windows' glass-window-background display item needs to force a transparent surface, and there can only be one
of those per window. So we store a reference to it in the nsDisplayListBuilder if there is one, and then we can
efficiently tell if any leaf display item is the one that forces a transparent surface. For display items that
wrap a list, we continue to store whether they need to force a transparent surface in a boolean in the list.
