753664 - Missing dir=rtl on Firefox dialogs that starts with an English letter

Status: NEW

(Toolkit :: General, defect)

Description

[Tomer Cohen :tomer]

Attachment: screenshot

When starting Firefox while we have a locked profile, it appears that the error message lost its direction. I suspect this is a regression as I never seen that before. 

Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0

Steps to reproduce:
a. Open Firefox.
b. Try to open again the same profile.

Comment 1

[Tomer Cohen :tomer]

Comment on attachment 622639 [details]
screenshot

The word "Firefox" should be the first in the paragraph ("Firefox is already open"), and on RTL locales should be the first word from the right.

Comment 2

[Simon Montagu :smontagu]

I guess this is a consequence of the HTML5 spec making alerts have auto-direction (implemented in bug 652550).

Unfortunately this will be a recurring problem in RTL localizations. I'm not sure if there is a more elegant and general solution than adding an RTL mark whenever the text of an alert happens to begin with an LTR word.

OTOH, I think one could make a case for making *all* chrome alerts follow the locale direction. This isn't necessarily even against the HTML spec, since the provision quoted at bug 652550 comment 13 can reasonably be interpreted as only applying to page scripts and not to alerts coming from the UI.

If so there will be some alerts that are left untranslated and appear as RTL even though the content is LTR, but I don't think that's such a tragedy.

Comment 3

[Aharon (Vladimir) Lanin]

(In reply to Simon Montagu from comment #2)

I agree with Simon on all points.

Comment 4

[Simon Montagu :smontagu]

So what we want to do is apply different CSS to a commonDialog or tabPrompt depending on whether it is opened from chrome or content. I have no idea how to make that distinction

Comment 5

[Tomer Cohen :tomer]

(In reply to Simon Montagu from comment #4)
> So what we want to do is apply different CSS to a commonDialog or tabPrompt
> depending on whether it is opened from chrome or content. I have no idea how
> to make that distinction

As a workaround, we can add RLM in the beginning of each message. I'd prefer not to add more rules to intl.css as it is very difficult to maintain, but doing so will lead to the following problems: 

* How are we going to find each dialog box at risk? (Is it possible to automate it somehow?)

* Having this workaround could be temporary solution, but there is nothing more permanent than temporary solution, so we'd need to document how to deal with such dialog boxes in the future. 



Is there a better and more HTML5-ish solution to how to deal with such problems we should be aware of?

Comment 6

[Simon Montagu :smontagu]

dolske, can you advise me how to determine whether a commonDialog or tabPrompt is being opened from chrome or content?

Comment 7

[Tomer Cohen :tomer]

(In reply to Simon Montagu from comment #6)
> dolske, can you advise me how to determine whether a commonDialog or
> tabPrompt is being opened from chrome or content?

Maybe it's time to propose second parameter to window.alert for features, similar to the third parameter on window.open, and have a feature for message direction similar to dir=(rtl|ltr) on HTML.

https://developer.mozilla.org/en-US/docs/DOM/window.open
https://developer.mozilla.org/en-US/docs/DOM/window.alert

Comment 8

[Simon Montagu :smontagu]

Attachment: Using @-moz-document to reset unicode-bidi on chrome documents

Comment 9

[Dão Gottwald [:dao]]

Comment on attachment 682561 [details] [diff] [review]
Using @-moz-document to reset unicode-bidi on chrome documents

>+/* reset unicode-bidi to normal in chrome documents (bug 753664) */
>+@-moz-document url-prefix("chrome://") {
>+    #info\.body {
>+	unicode-bidi: normal;
>+    }
>+}

indentation is messed up (too many spaces and a tab stop)

Both and commonDialog.css and tabprompts.css are chrome-only, so the @-moz-document restriction isn't needed.

Comment 10

[Simon Montagu :smontagu]

(In reply to Dão Gottwald [:dao] from comment #9)

> Both and commonDialog.css and tabprompts.css are chrome-only, so the
> @-moz-document restriction isn't needed.

I can't understand this. Adding unicode-bidi: plaintext in these files fixed bug 652550 for alerts from web content, and the patch here doesn't seem to regress that.

In any case, if you want to suggest a better way to distinguish between alerts from content and alerts from chrome in order to fix this bug, I'm all ears.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

The prompt document itself is always a chrome document, as dao suggests. What you care to distinguish is whether it was _triggered_ from content, which isn't something you can do with @-moz-document. I'm not sure what the best way to do that is, we may need to adjust the prompt API or introduce a new flag or something.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.