346234 - Text after highlight disappears with a large string of unbroken characters, e.g. in text input/field or page contents

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect)

Description

[Wayne Woods]

Follow-on from bug 237085 comment 74....

If you have a suitably large, unbroken string of characters in a field and highlight one or more of them, then all characters after that highlight vanish. Like bug 237085, the number of characters required to cause the bug is dependent upon text size... the bigger, the fewer.

To reproduce, look at the URL I entered above (assuming it works), which was taken from the previous bug. Highlight one or more characters, and all the ones to the right of it should vanish (at least in ltr text). Click on the link and open the page. Highlight some of the URL in the location bar and observe that it also bugs out there.

I'll provide an attachment next to observe the effect in page contents.

Comment 1

[Wayne Woods]

Attachment: Two long lines of Xs.

To demonstrate the bug in page contents. Two long lines of Xs. Highlight one and all subsequent ones should vanish.

Comment 2

[Wayne Woods]

Attachment: Two long lines of Xs

Oops. Didn't attach the previous one in a suitable format.

Comment 3

[Wayne Woods]

Also of note, this only seems to be a trunk bug. Couldn't reproduce with the latest Moz 1.8 nightly.

Comment 4

[Wayne Woods]

Can't reproduce in SeaMonkey (trunk), either. I guess this is a Firefox-only issue...

Comment 5

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

I think this is a cairo clipping bug. I saw it before myself in cairo builds (but not in non-cairo builds). We pass a huge clipping rect to cairo and I think it gets mangled when cairo converts coordinates to fixed point.

Comment 6

[Wayne Woods]

I wonder if this maybe isn't a Cairo bug.. I can reproduce this on Mac, despite the fact that Mac also still exhibits bug 237085, which tends to hide the text entirely. If I open attachment 231055 [details] (above) on Mac, and adjust the default text size so that one row of Xs appears, but not the other (which is 11 pt for me), and then highlight an X, I can see this bug (rest of the text vanishes). Going back over old builds, it appears that this started between the 20050502 and 20050503 trunk nightlies. I didn't think Cairo was switched on then... especially not for Mac.

It looks like the (font size) : (text length) ratio required to reproduce this bug is just a little lower than that of bug 237085. So I think unless you got the size *just* right, you never saw this bug because the latter hid the text entirely. But now that that's fixed on Windows, this bug has become visible at any font size over the minimum.

Comment 7

[baffclan]

*** Bug 347581 has been marked as a duplicate of this bug. ***

Comment 8

[Miroslav Juhos]

*** Bug 331086 has been marked as a duplicate of this bug. ***

Comment 9

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

It could be a cairo bug AND a Mac bug if they both have problems when setting a very large clipping rect of more than 32767 pixels.

Comment 10

[Phil Ringnalda (:philor)]

*** Bug 363683 has been marked as a duplicate of this bug. ***

Comment 11

[Cees T.]

Attachment 231055 [details] WFM, Firefox 2.0.0.2 on K/Ubuntu Linux 6.10. Making the text size really big causes Firefox to render the line over itself creating a black bar, but that's a different bug.

Comment 12

[baffclan]

cannot reproduce on Firefox/2007072905-trunk/WinXP.

WFM?

Comment 13

[Wayne Woods]

(In reply to comment #12)
> cannot reproduce on Firefox/2007072905-trunk/WinXP.
> WFM?

Yeah, WFM too.

Out of interest, I'll test in older builds tonight and see if I can work out what fixed it.

Comment 14

[Wayne Woods]

Fixed between 20070620-04 and 20070621-04 nightlies.

Looks like it was bug 367177 ("Turn on nsTextFrameThebes").