Closed Bug 1169648 Opened 5 years ago Closed 4 years ago

[e10s] The text in the title attribute is displayed in the wrong direction with RTL interface

Categories

(Core :: Layout: Text and Fonts, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---
firefox41 --- affected
firefox48 --- fixed
firefox49 --- fixed
firefox50 --- fixed

People

(Reporter: over68, Assigned: smontagu)

References

()

Details

(Keywords: reproducible, rtl, testcase)

Attachments

(2 files)

The text in the title attribute is displayed in the right direction with RTL interface.

Testcase https://dl.dropboxusercontent.com/u/95157096/85f61cf7/se6xng2lz6.html

Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/ec8asppab7.png
Component: General → Untriaged
Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150527030204
Locale: he

Neither lang="en" or dir="ltr" make a difference.
This can also be reproduced on this page: for example, hover over the word “Whiteboard” near the top.
Blocks: e10s
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: unspecified → Trunk
tracking-e10s: --- → ?
The HTML spec specifies at https://html.spec.whatwg.org/multipage/rendering.html#text-rendered-in-native-user-interfaces that "Text from attributes is expected to be rendered in a manner that honours the directionality of the attribute".

(We don't get this quite right in non-e10s either: we honour the directionality of the *element*, which is the same thing most of the time, but not in the case of an element with dir="auto" where the content of the element is LTR and the content of the attribute is RTL (or vice versa), but that is a separate bug).

If I'm looking in the right place, the code added in bug 938904 to display title tooltips doesn't seem to track the element to which the title belongs.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(enndeakin)
Filed bug 1169986 on the attribute/element directionality issue.
Hopefully Neil can take this on since I know so little about RTL issues.
Flags: needinfo?(wmccloskey)
> If I'm looking in the right place, the code added in bug 938904 to display
> title tooltips doesn't seem to track the element to which the title belongs.

We'll have to get the directionality from the element within ChromeTooltipListener::sTooltipCallback (in DocShellTreeOwner.cpp) and add it as an argument to all of the showTooltip methods until we get to XULBrowserWindow.showTooltip (in browser.js) where it can be assigned onto the label.
Flags: needinfo?(enndeakin)
same problem , " - e10s" added after each title on tabs
40.0a2 (2015-06-27)  - 64bit
Summary: [e10s] The text in the title attribute is displayed in the right direction with RTL interface → [e10s] The text in the title attribute is displayed in the wrong direction with RTL interface
(In reply to Neil Deakin from comment #5)
> > If I'm looking in the right place, the code added in bug 938904 to display
> > title tooltips doesn't seem to track the element to which the title belongs.
> 
> We'll have to get the directionality from the element within
> ChromeTooltipListener::sTooltipCallback (in DocShellTreeOwner.cpp) and add
> it as an argument to all of the showTooltip methods until we get to
> XULBrowserWindow.showTooltip (in browser.js) where it can be assigned onto
> the label.

We'll probably need all of the resolved directionality, the dir attribute, and the writing-mode, to fix this bug and also bug 1169986 and bug 1183691.
Attached patch Patch v.0Splinter Review
This gets us parity with non-e10s. For future extension to include writing-mode and dir (and/or unicode-bidi) it might make more sense to pass some kind of bit field instead of the raw CSS value, or just passing the computed style. I tried doing that but it didn't work out well: there were build errors like
 /Users/smontagu/mozwork/hgtree/mozilla/ipc/chromium/src/chrome/common/ipc_message_utils.h:115:19: error: no member named 'Write' in 'IPC::ParamTraits<nsIDOMCSSStyleDeclaration>'
   ParamTraits<P>::Write(m, p);
   ~~~~~~~~~~~~~~~~^
 /Users/smontagu/mozwork/hgtree/mozilla/obj-x86_64-apple-darwin13.4.0-debug.noindex/ipc/ipdl/_ipdlheaders/mozilla/dom/PBrowserChild.h:1241:14: note: in instantiation of function template specialization 'IPC::WriteParam<nsIDOMCSSStyleDeclaration>' requested here
         IPC::WriteParam(msg__, v__);
              ^
 ./PBrowserChild.cpp:1340:5: note: in instantiation of function template specialization 'mozilla::dom::PBrowserChild::Write<nsIDOMCSSStyleDeclaration>' requested here
     Write(tooltipStyle, msg__);

but I assume that that's a solveable problem)
Assignee: nobody → smontagu
Attachment #8635322 - Flags: feedback?(enndeakin)
IIRC, we've got some cases already where we pass a mozilla::WritingMode value between the processes, as part of the support for input methods; presumably we could do the same thing here.
Attachment #8635322 - Flags: feedback?(enndeakin) → feedback+
Hi,

I wasn't able to reproduce this issue on Windows 10, 7, Ubuntu 14.04 and Mac OS X 10.7 on the latest Aurora (46.0a2). In all cases the tooltip strings were correctly aligned to the left. I've tested this using the testcase that was provided and by hovering the Whiteboard on this site.

Build ID    20160209004008
User Agent  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
User Agent  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:46.0) Gecko/20100101 Firefox/46.0

Thanks,
Cipri
Flags: needinfo?(smontagu)
I can still reproduce it in a nightly build if "Enable multi-process" is checked in about:preferences. Is that checked in your testing environment?
Flags: needinfo?(smontagu) → needinfo?(ciprian.muresan)
Attached image tooltip string.png
Tested just now on Windows 10 and Mac on the latest Nightly. Made sure "Enable multi-process" is checked and I can't reproduce this.

Added "tooltip string.png" to make sure I'm doing this right.
Flags: needinfo?(smontagu)
You don't seem to be using RTL interface. Set intl.uidirection.en to "rtl" in about:config, or use https://addons.mozilla.org/en-us/firefox/addon/force-rtl/
Flags: needinfo?(smontagu)
Flags: needinfo?(ciprian.muresan)
Priority: -- → P3
Blocks: e10s-rtl
This was covered by bug 1236991 right?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Neil Deakin from comment #14)
> This was covered by bug 1236991 right?

Per comment #15, yup!
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.