361545 - Last line not selected when dragging downwards to following whitespace, in certain cases of Bidi with letter-spacing, word-spacing, etc.

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Uri Bernstein]

This is a spin-off from bug 361229.

In the linked testcase, start selecting from somewhere in the right-side section of the text, and drag downwards to the space to the right of the last line (but not below it!).
The last line should be selected, but is not.

This happens when the text ends with a whitespace-only bidi continuation frame, and is styled in a way that causes GetPositionSlowly() to be invoked (e.g., using word-spacing or letter-spacing).

The cause of this is given in (perhaps too much) detail in bug 361229 comment 4 (stages 1-9 are those relevant to this bug). The short version is:

- nsTextFrame::IsEmpty() does not consider the whitespace continuation frame to be empty, so GetSelectionClosestFrame() returns it.
- GetPositionSlowly() is then called for this frame. It /does/ consider the frame to be empty, and therefore fails (returns null).

I'm not sure what's the right way to fix this, and I probably won't have much time to do it anyway, so help is welcomed here.

Comment 1

[Uri Bernstein]

Attachment: patch (diff -w)

I guess we can fix it by not failing on empty frames in GetPositionSlowly() - I noticed that I had introduced the exact same change to GetPositionHelper() in bug 298690 (for different reasons).

Rob, is this worth getting in, or is this method going to be blown out by your nsTextFrame rewrite anyway?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Let's hold off until new textframe is on. At that point we'll have to deal with a completely different set of textframe bugs.

Comment 3

[Uri Bernstein]

WFM now, presumably fixed by the new TextFrame.

Comment 4

[Eyal Rozenberg]

Every cloud has a silver lining I guess...