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 ======================
Created attachment 54585 [details] testcase
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?
I think this was fixed in another bug. *** This bug has been marked as a duplicate of bug 57746 ***