STR: 1. Create a HTML file that starts with underscore (_page.html) 2. console.log something from the page 3. Look at the message logged in console Expected: The filename is displayed as _page.html:2:1 Actual: Filename displayed as page.html:2:1_ Caused by the "direction: rtl" rule at [1] that is there to show ellipsis on the left side of a long filename (...ng-file.js) Regressed by bug 1281732. [1] https://dxr.mozilla.org/mozilla-central/source/devtools/client/themes/webconsole.css#115

Due to the role the underscore (_) character has in Unicode bidirectional algorithm, this markup: <p style="direction: rtl">_page.html:1___</p> is reordered and rendered as "___page.html:1_" I solved it by creating a LTR embedding like this: <p style="direction: rtl"> <span style="direction: ltr; unicode-bidi: embed">_page.html:1___</span> </p> There is a new element with class "frame-link-source-inner" with the "unicode-bidi" CSS property. This markup achieves two goals: - the file name is truncated with ellipsis on the left side - the content is LTR and no RTL reordering is performed

Applying exactly the same fix to the netmonitor JS stacktrace tooltip. It doesn't use the React frame.js component yet, so needs to be fixed separately.

Comment on attachment 8775559 [details] [diff] [review] Console: filename starting with underscore is incorrectly displayed due to direction: rtl Review of attachment 8775559 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/client/themes/webconsole.css @@ +120,5 @@ > > +.stack-trace .frame-link-source-inner, > +.message-location .frame-link-source-inner { > + direction: ltr; > + unicode-bidi: embed; AFAICT this is ok. I've chatted a bit in #developers and read: https://drafts.csswg.org/css-writing-modes-3/#unicode-bidi and this is close to what happens when you do [dir] (it's using 'isolate' instead of 'embed' but since this is only ever one line it seems it would have the same outcome). This could use a comment explaining that otherwise '_script.js' gets displayed as 'script.js_'

Comment on attachment 8775583 [details] [diff] [review] Netmonitor stack trace: filename starting with underscore is incorrectly displayed due to direction: rtl Review of attachment 8775583 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/client/themes/tooltips.css @@ +425,5 @@ > overflow: hidden; > text-overflow: ellipsis; > } > > +.stack-frame-source-name-inner { This could also use a comment as in the other patch

Added comments to the non-obvious CSS styles

Added comments to the non-obvious CSS styles

Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/fx-team/rev/b47bbefc2b98 Console: filename starting with underscore is incorrectly displayed due to direction: rtl r=bgrins https://hg.mozilla.org/integration/fx-team/rev/deb448634afa Netmonitor stack trace: filename starting with underscore is incorrectly displayed due to direction: rtl r=bgrins

(In reply to Brian Grinstead [:bgrins] from comment #4) > AFAICT this is ok. I've chatted a bit in #developers and read: > https://drafts.csswg.org/css-writing-modes-3/#unicode-bidi and this is close > to what happens when you do [dir] (it's using 'isolate' instead of 'embed' > but since this is only ever one line it seems it would have the same > outcome). From what I read in the spec you mention, the difference between 'embed' and 'isolate' is how the box is treated from 'outside' when surrounded by other text. As this box is the only child of its parent, the difference shouldn't matter. I think that specifying the direction and unicode-bidi properties as CSS rules is better than HTML markup attributes in this case: it doesn't indicate the language of the contained text (that would be a good use case for HTML attributes), but specifies the styling and layout of the content. > This could use a comment explaining that otherwise '_script.js' gets > displayed as 'script.js_' Added the comments to the CSS files.

https://hg.mozilla.org/mozilla-central/rev/b47bbefc2b98 https://hg.mozilla.org/mozilla-central/rev/deb448634afa

I have reproduced this bug with Firefox nightly 50.0a1(build id:20160728030208)on windows 7(64 bit) I have verified this bug as fixed with Firefox aurora 50.0a2(build id:20160909004004) User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 [testday-20160909]