It appears that the the text is drawn as multiple overlapping strings of text. What is interesting is that the number of characters you need to type varies based on font, font size and character width, so it must depend on the total length of the string in pixels as drawn on the screen. Depending on exactly how Mozilla draws text, this could of course be a bug in GTK2. This may or may not be the same as bug 35229, since trev on irc reported that he didn't see the problem on windows, but that the text dissapeared after 65536 characters. Clearly the same kind of problem, however. I'll attach a screenshot of this bug in action on my computer for clarity.
Created attachment 153756 [details] screenshot of mozilla exhibiting the bug In this screenshot the url in question is a data: url containing an image. You'll notice that while this happens in the <textbox>es in the urlbar and page info, it doesn't happen in the treecell.
also, now that I think about it, I can demonstrate the problem by putting that data url into the url field of this bug, as it also occurs in text inputs. :)
there are no spaces and the line doesn't wrap.. dup of bug 99457?
No, this bug is only about the rendering defect that occurs in textboxes. It doesn't matter if the string contains spaces, the problem still occurs becuase textboxes are all single line. The source of a page containing a long string with no spaces like this will also trigger bug 99457, but it's still a different bug. (I guess a <textarea> would also have less of a problem if it could wrap the text.)
looks fine here with current trunk
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.