Summary: | REGRESSION: Assertion in RenderBox::mapAbsoluteToLocalPoint when loading a page with a scrollable RenderLayer | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Beth Dakin <bdakin> | ||||||
Component: | Layout and Rendering | Assignee: | Beth Dakin <bdakin> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aroben, bdakin, jchaffraix, mitz, sam, simon.fraser, thorton, tony, webkit-bug-importer, xji | ||||||
Priority: | P2 | Keywords: | InRadar, Regression | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.7 | ||||||||
Attachments: |
|
Description
Beth Dakin
2011-11-29 12:34:07 PST
Created attachment 117023 [details]
Test that asserts
I looked at this briefly in the debugger, and immediateScrollToPoint() is called with the point (0,0). It doesn't make sense to call notifyPositionChanged() in that case because, since the page it just loading and laying out for the first time, the position has not changed. The reason to trigger notifyChange is explained at: https://bugs.webkit.org/show_bug.cgi?id=70395#c2 We probably need a better way to distinguish the situations. Sam is probably the person knowing the code the best. Is the assertion triggered by just loading the attached test case in a debug build? I tried it, but it does not tigger assertion, neither when I scroll/resize the page. The assertion will only happen on Mac OS X Lion with overlay scrollbars since it involves the new overlay scrollbar code. Are you running Lion and using overlay scrollbars? In that configuration, for me, the assertion fires on load. No wonder it does not crash for me in Mac and Chromium. I am running Snowleopard. Is this a dupe of bug 69187? I'm seeing this all the time. (In reply to comment #7) > Is this a dupe of bug 69187? > > I'm seeing this all the time. It certainly seems so! I guess this was a crash we always had, but http://trac.webkit.org/changeset/100819 definitely seems to make it happen much more frequently. *** Bug 69187 has been marked as a duplicate of this bug. *** It's wrong to be calling Scrollbar::convertFromContainingView() in the middle of layout, since coordinates are in flux. Maybe we should postpone calls to RenderBlock::updateScrollInfoAfterLayout() until after layout is complete. *** Bug 73723 has been marked as a duplicate of this bug. *** (In reply to comment #11) > It's wrong to be calling Scrollbar::convertFromContainingView() in the middle of layout, since coordinates are in flux. Maybe we should postpone calls to RenderBlock::updateScrollInfoAfterLayout() until after layout is complete. If you look at that stack trace, you can see that this work is happening as a result of code in updateScrollInfoAfterLayout(). the layout state doesn't seem to be popped until after that. (In reply to comment #13) > (In reply to comment #11) > > It's wrong to be calling Scrollbar::convertFromContainingView() in the middle of layout, since coordinates are in flux. Maybe we should postpone calls to RenderBlock::updateScrollInfoAfterLayout() until after layout is complete. > > If you look at that stack trace, you can see that this work is happening as a result of code in updateScrollInfoAfterLayout(). the layout state doesn't seem to be popped until after that. Oh, I just misunderstood you. I see you are saying that updateScrollInfoAfterLayout() itself should maybe be postponed. Created attachment 118296 [details]
Patch
Fixed with http://trac.webkit.org/changeset/102355 Filed https://bugs.webkit.org/show_bug.cgi?id=74111 to cover the not-regularly-reproducible occurrence of this assertion. |