Bug 38226 – Full width spaces are collapsed in option element

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Text

[Xianzhu Wang]

URLs (if applicable) : 
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Chrome 5: FAIL
  Firefox 3.x: OK
         IE 8: OK

What steps will reproduce the problem?
1. Open the attached test case

What is the expected result?
The text in the selection box should be like this:
======================
    full-width spaces
  non-breakable-spaces
normal-spaces
======================

What happens instead?
Full width spaces are incorrectly collapsed:
======================
full-width spaces
  non-breakable-spaces
normal-spaces
======================

[Xianzhu Wang]

Created attachment 54585 [details]
testcase

[Xianzhu Wang]

The reason that full-width spaces are collapsed is that the option element uses String::stripWhiteSpace() and String::simplifyWhiteSpace() which handle the set of white spaces different from the set of collapsable white spaces defined in HTML/CSS spec.

I think there are two ways of solutions:

1. Add String::stringHTMLWhiteSpace() and String::simplifyHTMLWhiteSpace() and call them from OptionElement. In this way, the code change is small, but we can't share the same code with existing HTML/CSS white space handling.

2. Refactor rendering of select element and option element, let option elements be rendered as text blocks, thus take advantage of existing HTML/CSS white space handling. In this way, we can also allow the style of select/option to be controlled by CSS, such as text wrapping, word breaking, hover color, margin and padding, etc. Some hard-coded features, such as optgroup indentation, can also be implemented with CSS.

I'd like to hear more opinions.

Can we directly modify the WTF::String function;


static inline bool isSpaceOrNewline(UChar c) 

like; this is checking whether it is an ASCII space or a Unicode space (using the ICU function for directionality information) in the conditional statement.

Hence can we just have a check for this full-width charatcter before this conditional statement as follows;
 
if (c == 0x3000)
return false;
 
which will basically return false from there itself, interpreting it as non-white space character, which is the way I feel bcoz U+3000 (full-width space) should not be considered for any whitespace/newline procerssing as per its properties I guess. 
 
Does this impact any thing else, bcoz I could see this function being used in a number of places, especially in rendering, loader etc?

[Kent Tamura]

I think this was fixed in another bug.

*** This bug has been marked as a duplicate of bug 57746 ***