[Webkit-unassigned] [Bug 76801] Listboxes incorrectly display contents when cleared and then re-populated
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jan 26 22:47:32 PST 2012
https://bugs.webkit.org/show_bug.cgi?id=76801
--- Comment #14 from Joe Thomas <joethomas at motorola.com> 2012-01-26 22:47:32 PST ---
(In reply to comment #13)
> Hmm... I don't know this code all that well, but I doubt that this is the most elegant approach. We shouldn't have to scroll - ScrollableArea should reset scroll position on its own when its content shrinks. Why doesn't that happen?
>
ScrollableArea is the base class of RenderListBox and it gets the scroll-offset from RenderListBox (using ScrollableArea::scrollToYOffsetWithoutAnimation)
In the given use case, when the list-items get removed, we disable the scroll bar in RenderListBox::computeLogicalHeight but we never updates the scroll offset with ScrollableArea.
In the patch, I am calling scrollToYOffsetWithoutAnimation(0) after disabling the scrollbar, so apart from updating the offsets at ScrollableArea, it may not initiate any painting(not verified).
> Also, you say that this works after a programmatic scroll (so it's difficult to make a test), but not after a manual one. What causes the difference between these cases?
I did some more trials and this works in programmatic scroll only if we execute all the below steps in one go.
(1) populate();
(2) document.getElementById("myList").selectedIndex = 99;
(3) clear();
(4) populate();
Step 2 schedules a layout and the selectedIndex gets updated with ScrollableArea when RenderListBox::Layout gets called. But before layout happens, step 3 and 4 gets executed which sets scrollOffset of HTMLSelectElement back to -1. So ScrollableArea never gets updated with the selectedIndex.
If we break the above steps into 2 groups (first two steps in one group) and execute them separately, then the issue will be reproducible.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list