Closed Bug 652550 Opened 13 years ago Closed 12 years ago

Javascript Alert box always displays LTR or RTL according to UI direction, not the directionality of the content

Categories

(Toolkit :: General, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: sridhar.ibm, Assigned: smontagu)

References

(Depends on 2 open bugs, Blocks 1 open bug, )

Details

(Keywords: rtl)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16
Build Identifier: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

When an alert box is showed in FF4, the test does not appear RTL. It appears LTR. The text itself is Arabic/Hebrew and the browse was run in proper locale. 
Is this a bug? Is there a way to display proper text formatting for bidi string messages in an alert box?

Reproducible: Always

Steps to Reproduce:
1.Display an alert box containing"برنامج الاستعراض الذى تقوم باستخدامه غير مدعوم حاليا.  يرجى استخدام FireFox 3.6، أو Internet Explorer 7، أو Internet Explorer 8.  اذا تم الاستمرار في استخدام برنامج الاستعراض هذا قد تحدث  مشاكل في الشكل والمضمون بالاضافة الى مشاكل وظيفية." 
2.
3.

Actual Results:  
The javascript alert popup should have displayed proper RTL. Instead it display LTR.

Expected Results:  
The javascript alert popup should have displayed proper RTL. Instead it display LTR.
Keywords: rtl
Sridhar,
Can you attach a testcase or the site you are trying to view.
I am not sure we can switch the popup alert display to RTL. Alert box contents can be LTR in an RTL browser (e.g. a deliberately non-localized error/warning message, or caused by a javascript:alert() call in the location bar).
What did Firefox 3.6 do here? [And does Firefox 4 do the same if you flip the prompts.tab_modal.enabled pref?]

We could make the prompt inherit the direction from the page, though I don't know if that's correct/expected.

A site-based workaround might be to use the unicode RTL/LTR marks to control the direction of the supplied text.
Product: Firefox → Toolkit
QA Contact: general → general
RTL Firefox 3.6 display RTL popup alert. I tested an old build of Firefox 4 on Windows 7 and the popup alert was also RTL, so perhaps this bug is a regression. Can anyone confirm this bug on a recent win32 build?
RTL Firefox has the reverse bug: all popups are displayed RTL. Changing summary to reflect this.

See http://www.w3.org/International/docs/html-bidi-requirements/#script-dialog. I thought this bug already existed among the dependencies of bug 613154, but apparently it doesn't.
Blocks: html5bidi
Depends on: DirAuto
Summary: Javascript Alert box displays LTR instead of RTL Arabic and Hebrew (right to left incorrect) → Javascript Alert box always displays LTR or RTL according to UI direction, not the diretionality of the content
Summary: Javascript Alert box always displays LTR or RTL according to UI direction, not the diretionality of the content → Javascript Alert box always displays LTR or RTL according to UI direction, not the directionality of the content
RTL testcase:
javascript:alert("فَيَرفُكس 4 (Firefox 4) هنا!\nshould display as \n\u202Bفَيَرفُكس 4 (Firefox 4) هنا!\u202c");

LTR testcase:
javascript:alert("Firefox 4 تنزيل مجاني from mozilla.com\nshould display\n\u202aFirefox 4 تنزيل مجاني from mozilla.com\u202c");
Status: UNCONFIRMED → NEW
Ever confirmed: true
Simon is right.  Without dir=auto, there is no good way to fix this.  :(
What do other browsers do here? We might not be able to fix it "correctly", but we should probably at least be consistent to lessen webdev pain, if possible...
(In reply to comment #8)
> What do other browsers do here? We might not be able to fix it "correctly", but
> we should probably at least be consistent to lessen webdev pain, if possible...
Generally browsers adopt the UI direction, but for us things are different, since alerts are no longer a modal dialog, so it may not make sense to apply the UI direction to them.  Furthermore, I meant that the correct solution (automatic direction based on the alert content) is not achievable yet.  I didn't mean to suggest that we shouldn't do anything here until we can fix it correctly.
Attached patch PatchSplinter Review
As Aharon points out in bug 703234, this is trivial to fix now that we have support for unicode-bidi: [-moz-]plaintext.

Is there a way to reftest prompt boxes?
Assignee: nobody → smontagu
Attachment #575214 - Flags: review?(dolske)
Comment on attachment 575214 [details] [diff] [review]
Patch

It would kinda be nice to have a test for this, though I'm not quite sure how it would check that we're showing the text correctly. (There are existing tests in /toolkit/components/prompts/test/, if you happen to think of a way.)

r+ with or without a test.
Attachment #575214 - Flags: review?(dolske) → review+
(In reply to Simon Montagu from comment #11)
> Created attachment 575214 [details] [diff] [review] [diff] [details] [review]
> Patch
> 
> As Aharon points out in bug 703234, this is trivial to fix now that we have
> support for unicode-bidi: [-moz-]plaintext.
> 
> Is there a way to reftest prompt boxes?

Just so it's all in one place, I am copying here some info from bug 703234:

The HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#text-rendered-in-native-user-interfaces, in response to http://www.w3.org/Bugs/Public/show_bug.cgi?id=10827) states:

A string provided by a script (e.g. the argument to window.alert()) is expected to be treated as an independent set of one or more bidirectional algorithm paragraphs when displayed, as defined by the bidirectional algorithm, including, for instance, supporting the paragraph-breaking behaviour of U+000A LINE FEED (LF) characters. For the purposes of determining the paragraph level of such text in the bidirectional algorithm, this specification does not provide a higher-level override of rules P2 and P3.

The last sentence implies that each paragraph's directionality is determined by the paragraph's first character with strong directionality. This is easily achieved by applying unicode-bidi:plaintext to the preformatted whitespace element used to show the dialog text. (BTW, unicode-bidi:plaintext is the default for <pre dir=auto>.)
https://hg.mozilla.org/integration/mozilla-inbound/rev/2c0351bbc65d
Flags: in-testsuite?
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/2c0351bbc65d
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
I just applied the Nightly update, and this indeed seems to be working according to spec now. Yay!
Depends on: 753664
Depends on: 766557
You need to log in before you can comment on or make changes to this bug.