Last Comment Bug 588996 - -moz-locale-dir selector should work in html documents
: -moz-locale-dir selector should work in html documents
Status: ASSIGNED
: rtl
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Mano (::mano, needinfo? for any questions; not reading general bugmail)
:
: Jet Villegas (:jet)
Mentors:
: 1201640 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-19 16:43 PDT by Mano (::mano, needinfo? for any questions; not reading general bugmail)
Modified: 2015-09-28 05:36 PDT (History)
13 users (show)
arni2033: needinfo? (asaf)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
screenshot 2015.09.28 15-26-23.png (85.29 KB, image/png)
2015-09-28 05:27 PDT, arni2033
no flags Details

Description Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-08-19 16:43:36 PDT
Currently, -moz-locale-dir is supported only within xul documents.  In html documents this selector always matches ltr.   I assume this was done for a reason: the code within nsXULDocument::IsDocumentRightToLeft has nothing to do with xul.

With remote xul going away now, this makes -moz-locale-dir usable only within chrome:// UI.  However, there are already few UI documents that are rendered within the content area.  For now, they fallback to using  global.dtd's locale.dir and complex selectors (body[dir="rtl"] > ...)

At least for about: pages, I strongly suggest to enable this selector for non-xul documents.
Comment 1 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-14 15:01:06 PDT
Neil: ping?
Comment 2 Neil Deakin 2010-09-14 15:57:20 PDT
What would -moz-locale-dir return? The direction the chrome is in I presume?

Are you expecting this to be the same in remote web pages?

If so, probably, what need to happen is that the default implementation of nsDocument::IsDocumentRightToLeft() just needs to return nsIXULChromeRegistry::IsLocaleRTL("global", &isRTL);
Comment 3 Alan Thomas 2010-11-01 02:49:07 PDT
This happens on Windows too. I suspect this bug's platform should be All.
Comment 4 Tomer Cohen :tomer 2011-11-02 11:41:38 PDT
(In reply to Mano from comment #0)
> With remote xul going away now, this makes -moz-locale-dir usable only
> within chrome:// UI.  However, there are already few UI documents that are
> rendered within the content area.  For now, they fallback to using 
> global.dtd's locale.dir and complex selectors (body[dir="rtl"] > ...)
What's wrong with using global.dtd's locale.dir? It is working well right now.
Comment 5 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2011-11-02 14:03:08 PDT
What's the behavior when there's no global.dtd file? That is, is it ignored in other browsers?
Comment 6 Tomer Cohen :tomer 2011-11-02 14:09:14 PDT
(In reply to Mano from comment #5)
> What's the behavior when there's no global.dtd file? That is, is it ignored
> in other browsers?

global.dtd is available on Mozilla applications, and thous I don't see why we should use another method to retrieve the UI direction. Please correct me if I'm wrong as I don't see any downsides in our current implementation.
Comment 7 Sebastian Zartner 2011-11-02 16:44:05 PDT
Please see http://code.google.com/p/fbug/issues/detail?id=4948 for a case, in which -moz-locale-dir could be needed.
Please let me know, if this could be solved differently.
Comment 8 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2011-11-03 00:36:46 PDT
Tomer, also note that -moz-locale-dir was introduced in order to remove locale.dir completely at some point.

Taking...
Comment 9 Sebastian Zartner 2011-12-25 09:46:28 PST
Is that already fixed? At least the reporter of the issue mentioned in comment 7 said, that it's already working for him now.

Sebastian
Comment 10 arni2033 2015-09-28 05:11:28 PDT
*** Bug 1201640 has been marked as a duplicate of this bug. ***
Comment 11 arni2033 2015-09-28 05:27:31 PDT
Created attachment 8666662 [details]
screenshot 2015.09.28 15-26-23.png

That selector still doesn't work in Aurora43 for RTL localization. I tested Hebrew localization
I believe this should be closed/reassigned (or left w/o assignee) if you're not going to work on this

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