Closed Bug 248708 Opened 18 years ago Closed 7 years ago
Problem with rendering & selection of "ignorable" characters in text field
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 When characters that map to the default glyph (generally a hollow box) are displayed in a text field (INPUT type="text"), various problems with rendering and selecting can be observed. (I'm a bit hesitant to report this, as it seems like something that would've been noticed long before now. However, I've read through a lot of bug reports, and couldn't find one that sounded exactly like it. If it's out there, then I sincerely apologise for wasting your time.) Reproducible: Always Steps to Reproduce: On the demonstration page (the URL entered above): Click 'Fill'; 32 characters are added to the field (I arbitrarily chose ASCII 0x01 as a character likely to map to the default glyph). The field still appears to be entirely blank. Clicking the field while it's apparently empty and typing normal characters (eg. 'a') will slowly "reveal" the 32 default glyphs. Mousing over the field or tabbing through the field after at least one normal character has been entered will cause it to be immediately rendered correctly (albeit temporarily). Reset the field, then click within it and enter a valid character (eg. 'a'). Click 'Fill'. The characters added won't appear immediately, but will snap into view if you mouse/tab into the field. Attempt to select within the field; selecting a range won't work (you're limited to highlighting the one valid character), but selecting the entire field by double-clicking or clicking & dragging outside of the frame works as expected. This also effects the clearing of the field occasionally (ie. after resetting the field, it's only partially cleared -- remnants of text are left behind), but it seems slightly less predictable. Actual Results: See above. Expected Results: See above. This was discovered with Firefox 0.8 and 0.9, then confirmed with Mozilla 1.7 and the latest nightly build of Mozilla 1.8a2.
Sounds like a Win32-only issue -- I'm not seeing it on Linux... I'd suggest attaching the testcase to the bug, by the way, so it won't disappear.
Whiteboard: gfx bug?
The original test case added as an attachment.
Okay, I took a quick look at the problem tonight. First look at the Mozilla source, first attempt to put in my two cents: if I'm out of line, or not following proper procedure, feel free to slap me around. First, it seems clear that Mr. Zbarsky is correct, and the bug is somewhere in the Win32 font classes. I'll try to change the 'Component' field in this bug report to GFX:Win32; hopefully that won't cause a catastrophe. Not sure about the QA Contact address, though... Here's what I've observed, so far: Briefly, after modifying the contents of the text field, there's a call to nsTextFrame::Reflow() that, in turn, calls nsTextFrame::MeasureText(). In the test case, when the text field is filled with characters that don't map to a glyph in the field's font, MeasureText() is returning a width of 0, which seems to be incorrect. Deeper than that, where the bug apparently lies, it's out of the layout classes and into the (Win32) gfx classes. Following it down, it seems that any glyphs not present in the field's proper font are mapped to a second font of type nsFontWinSubstitute. This class has a boolean member, mIsForIgnorable: I've yet to figure out what it means, but what it does is short-circuit the GetWidth() and DrawString() methods. In the case of GetWidth(), if mIsForIgnorable is set, it immediately returns 0 instead of building a string of substitute characters and returning the measured width of that string. If the test for mIsForIgnorable in nsFontWinSubstitute::GetWidth() (line 4405 of gfx/src/windows/nsFontMetricsWin.cpp) is commented out, the text field in the test case appears to work properly -- that is, the behaviour observed in the original bug report no longer occurs. I'm not in any way suggesting this as a patch, just the result of a couple of hours of looking around. If someone wants to take the ball and run with it, or push me in the right direction, that's great; otherwise, I'll keep at it myself until I figure out what's really going on. Cheers.
Component: Layout: Form Controls → GFX: Win32
Changed QA contact changed manually, since I wasn't permitted to reassign it; hopefully this isn't a breach of conduct. It'd be nice if this actually gets to someone who's willing to comment on it. Question: is the concept of "absorbing" ignorable characters (as defined by Unicode) at the rendering stage appropriate for an interactive application? I can see how this could apply in a pure rendering application -- sending a document to the printer, for example. However, when text can be selected and manipulated, it seems to me that some visual representation of "ignorable" characters should exist. I'm still trying to sort it out, so it's possible I've put my foot in my mouth; perhaps the bug is simply that substitution (and absorption) is occurring in rendering contexts where it's not meant to happen. At a glance, other platforms seem to handle ignorable characters in a similar manner; however, the (one) person who's checked this under Linux indicated that he didn't see the problem. Anyone?
QA Contact: core.layout.form-controls → ian
Summary: Problem with rendering & selection of default glyphs in text field. → Problem with rendering & selection of "ignorable" characters in text field.
Is the weirdness specific to the form input control? Can you emulate it inside a basis element such as <span>?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 245480 demonstrates the selection problem in a <p> element containing ignorable characters. Additionally, if you View | Page Source on his test case, on the same line you'll see a rendering problem where the word "questions..." meets a " entity and overlaps it. If you need more examples, let me know and I'll put something together.
So, we need '-moz-render-invisible-characters-visually' (see bug 205387 comment #36)? ...... 'pp' here is interesting. we plan to make other Gfx ports behave like Gfx:Win in bug 205387.... We have to come up with the way we want invisible characters to behave in input fields and other parts before beginning to work on this.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.