Last Comment Bug 729047 - <wbr> should have the same bidi effects as a U+200B, the zero width space
: <wbr> should have the same bidi effects as a U+200B, the zero width space
: dev-doc-complete
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla13
Assigned To: Simon Montagu :smontagu
Depends on: 178671
Blocks: 735850
  Show dependency treegraph
Reported: 2012-02-21 02:23 PST by Aharon (Vladimir) Lanin
Modified: 2012-06-17 18:02 PDT (History)
6 users (show)
smontagu: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (1.97 KB, patch)
2012-02-22 22:34 PST, Simon Montagu :smontagu
ehsan: review+
Details | Diff | Splinter Review
Aharon's test as reftest (1.38 KB, patch)
2012-02-22 22:35 PST, Simon Montagu :smontagu
ehsan: review+
Details | Diff | Splinter Review

Description User image Aharon (Vladimir) Lanin 2012-02-21 02:23:47 PST
Currently, data:text/html,<div dir=rtl>123,<wbr>456</div> is displayed as 456,123 (when it is not wrapped to two lines).

There are three things wrong with this:
- It gives you the wrong number with no hint to the user of what happened. We want it to display as 123,456, as if the <wbr> was not there.
- It is not what IE9 does (it displays 123,456)
- It seems to disagree with the HTML5 spec (, whose default style sheet section says:

wbr { content: '\200B'; }

Please note that U+200B, the ZERO WIDTH SPACE, is (unlike all the other space-type characters, e.g. U+200A, the HAIR WIDTH SPACE) of bidi class BN, which effectively has no effect on the bidi ordering of the content around it (see Thus data:text/html,<div dir=rtl>123,&%23x200B;456</div> displays as we want it to, i.e. 123,456.

Unfortunately, the HTML5 spec currently gives no more explicit indication of the effects the <wbr> is supposed to have on the bidi ordering of the content around it, and I have filed a bug on HTML5 ( about that. Also, the content spec in the default style sheet is rather strange, given that the <wbr> definition ( explicitly says that "content inside wbr elements must not be considered part of the surrounding text".

Nevertheless, I think that there is sufficient reason to change the bidi behavior of <wbr> to match that of U+200B (when the line is not wrapped at the <wbr>), without waiting for the last word from the HTML5 spec.

Please note that currently there are no good workarounds to this bug. Using &#x200B; instead of <wbr> results in a stupid invisible character in the page, which is no fun if the user cuts, pastes, and edits the content. Furthermore, unlike <wbr>, it does not work inside a <pre>. And adding wbr { content: '\200B'; } to the page's style currently does not seem to have any effect (perhaps the content pseudo-property is not supported yet?).
Comment 1 User image Aharon (Vladimir) Lanin 2012-02-22 03:49:28 PST
Does it really depend on bug 178671? The bidi behavior of <wbr> could be fixed without implementing <wbr> in CSS. Indeed that is what I would prefer given 178671 still being open since 2002 :-) - unless a fix already seems to be imminent.
Comment 2 User image Simon Montagu :smontagu 2012-02-22 08:44:43 PST
I think that fixing this via bug 178671 would be cleaner, but that seems to have various hidden pitfalls. See especially bug 178671 comment 8 and attachment 544285 [details] (from bug 485241). I'll test a bidi-only fix on try
Comment 3 User image Simon Montagu :smontagu 2012-02-22 22:34:45 PST
Created attachment 599879 [details] [diff] [review]
Comment 4 User image Simon Montagu :smontagu 2012-02-22 22:35:25 PST
Created attachment 599880 [details] [diff] [review]
Aharon's test as reftest
Comment 5 User image Aharon (Vladimir) Lanin 2012-02-23 00:25:33 PST
Thanks! I am no Mozilla reviewer, but the patch looks very clean to me.
Comment 6 User image :Ehsan Akhgari 2012-02-23 14:15:03 PST
Comment on attachment 599879 [details] [diff] [review]

Review of attachment 599879 [details] [diff] [review]:

::: layout/base/nsBidiPresUtils.cpp
@@ +1141,5 @@
>          // U+FFFC"
> +        // <wbr>, however, is treated as U+200B ZERO WIDTH SPACE. See
> +        //
> +        aBpd->AppendUnichar(content->Tag() == nsGkAtoms::wbr ?
> +                              kZWSP : kObjectSubstitute);

Please use content->IsHTML(nsGkAtoms::wbr).  Also, please fix the indentation.
Comment 8 User image Jean-Yves Perrier [:teoli] 2012-02-26 01:08:33 PST
I've explained the bidi behavior in
and added a note for the fix in:
Comment 9 User image Jean-Yves Perrier [:teoli] 2012-02-26 01:09:13 PST
Sorry I jumped somewhat the gun. I will amend the doc if it doesn't land in Fx 13 or is backed-out.
Comment 10 User image Phil Ringnalda (:philor) 2012-02-26 16:07:12 PST
Comment 11 User image Phil Ringnalda (:philor) 2012-02-26 16:07:48 PST
Well, and not surprisingly

Note You need to log in before you can comment on or make changes to this bug.