Summary: | Assertion failure in RenderBlock::positionForPointWithInlineChildren when running fast/inline/relative-positioned-overflow.html | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> | ||||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | darin, eric, hamaji, hyatt, mitz | ||||||||||
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure, PlatformOnly | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows XP | ||||||||||||
Attachments: |
|
Description
Adam Roben (:aroben)
2009-10-01 09:17:42 PDT
This test seems to pass in Release builds. Was this a regression? Do we know yet from which revision? Created attachment 43914 [details]
Patch v1
Created attachment 43915 [details]
test case
Created attachment 43916 [details]
Patch v2
Comment on attachment 43914 [details]
Patch v1
This was a bit older patch.
This issue happens when an empty inline element (which has size because of paddings) is clicked. In this case, the root inline box has no leaf children and closestBox can be NULL even if we are using windows behavior. We may need to use lastChild instead of lastLeafChild when lastLeafChild is NULL so that the mouse press starts from the empty inline element correctly. See the attached test case, which is the same HTML as the layout test I added, to see how dragging from an empty inline element is handled now. Chromium has the same issue: http://code.google.com/p/chromium/issues/detail?id=23751 Comment on attachment 43916 [details] Patch v2 Thanks for working on this bug! > + eventSender.mouseMoveTo(x, y + 50); > + eventSender.mouseDown(); > + eventSender.mouseMoveTo(x, y + 40); > + eventSender.mouseMoveTo(x, y + 30); > + eventSender.mouseMoveTo(x, y + 20); > + eventSender.mouseMoveTo(x, y + 10); > + eventSender.mouseMoveTo(x, y); > + eventSender.mouseUp(); Is there a reason to visit all the intermediate positions? I think you need just two mouseMoveTo()s, and even that is only because the selection start position is determined not on mouse down but on the first mouse move after that (which is arguably a bug). I think mouseMoveTo(x, y + 50); mouseDown(); mouseMoveTo(x, y + 50); mouseMoveTo(x, y); mouseUp(); will work. I don’t understand why this fix is correct. Just using a non-leaf child (which is not even necessarily a left in the line box tree, it may have nested inline boxes) in this case seems inconsistent. What if there is a line in the middle that has no leaf boxes. What if the first line that has children has no leaf boxes? It seems like we may end up calling positionForBox(null, …) in such cases because we consider lines that have no leaf boxes and then call {first,last,closest}LeafChild on them. Perhaps the right thing to do is in the initial vertical scan loop, change if (!root->firstChild()) continue; to if (!root->firstLeafChild()) continue; so that only lines with leaf child boxes are considered. Did you try that? (In reply to comment #9) > is not even necessarily a left in the line box tree, it may have nested inline typo: s/left/leaf/ Created attachment 43926 [details]
Patch v3
Thanks for your quick review! > Is there a reason to visit all the intermediate positions? I think you need > just two mouseMoveTo()s, and even that is only because the selection start > position is determined not on mouse down but on the first mouse move after that > (which is arguably a bug). I think mouseMoveTo(x, y + 50); mouseDown(); > mouseMoveTo(x, y + 50); mouseMoveTo(x, y); mouseUp(); will work. Ah, it works. As this was my first patch around selection and inline flows, I've just emulated other tests in the same directory after I noticed mouseMoveTo(x, y+50); mouseDown(); mouseMoveTo(x, y); mouseUp(); doesn't work due to the bug you mentioned. > I don’t understand why this fix is correct. Just using a non-leaf child (which > is not even necessarily a left in the line box tree, it may have nested inline > boxes) in this case seems inconsistent. What if there is a line in the middle > that has no leaf boxes. What if the first line that has children has no leaf > boxes? It seems like we may end up calling positionForBox(null, …) in such > cases because we consider lines that have no leaf boxes and then call > {first,last,closest}LeafChild on them. Perhaps the right thing to do is in the > initial vertical scan loop, change > if (!root->firstChild()) > continue; > to > if (!root->firstLeafChild()) > continue; > > so that only lines with leaf child boxes are considered. Did you try that? Yeah, you are right. I studied the code of inline box for a while... it was insufficient :( My understanding about the structure of inline boxes were completely wrong. Now I think I have a better understanding thanks to your comment. Thanks! I'll commit this patch tomorrow after I re-check the patch destroys nothing. Committed as http://trac.webkit.org/changeset/51429 |