[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