[Webkit-unassigned] [Bug 29966] Assertion failure in RenderBlock::positionForPointWithInlineChildren when running fast/inline/relative-positioned-overflow.html

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29966





--- Comment #12 from Shinichiro Hamaji <hamaji at chromium.org>  2009-11-26 10:35:44 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.