248708 - Problem with rendering & selection of "ignorable" characters in text field.

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX: Win32, defect)

Description

[Robert Barnhardt]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Robert Barnhardt]

Attachment: Test Case

The original test case added as an attachment.

Comment 3

[Robert Barnhardt]

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.

Comment 4

[Robert Barnhardt]

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?

Comment 5

[rbs]

Is the weirdness specific to the form input control? Can you emulate it inside a
basis element such as <span>?

Comment 6

[Robert Barnhardt]

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 &quot; entity and overlaps it.

If you need more examples, let me know and I'll put something together.

Comment 7

[Jungshik Shin]

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. 

Comment 8

[Gordon P. Hemsley [:GPHemsley]]

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]