blinky Reporter
	Description • 9 years ago

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

	Gingerbread Man
	Comment 1 • 9 years ago

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.

	Simon Montagu :smontagu Assignee
	Comment 2 • 9 years ago

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.

	Simon Montagu :smontagu Assignee
	Comment 3 • 9 years ago

Filed bug 1169986 on the attribute/element directionality issue.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 4 • 9 years ago

Hopefully Neil can take this on since I know so little about RTL issues.

	Neil Deakin
	Comment 5 • 9 years ago

> 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.

	Shahab Morovati
	Comment 6 • 9 years ago

same problem , " - e10s" added after each title on tabs
40.0a2 (2015-06-27)  - 64bit

	Simon Montagu :smontagu Assignee
	Comment 7 • 9 years ago

(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.

	Simon Montagu :smontagu Assignee
	Comment 8 • 9 years ago

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)

	Jonathan Kew [:jfkthame]
	Comment 9 • 9 years ago

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.

	Ciprian Muresan [:cmuresan], Ecosystem QA
	Comment 10 • 8 years ago

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

	Simon Montagu :smontagu Assignee
	Comment 11 • 8 years ago

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?

	Ciprian Muresan [:cmuresan], Ecosystem QA
	Comment 12 • 8 years ago

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.

	Simon Montagu :smontagu Assignee
	Comment 13 • 8 years ago

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/

	Neil Deakin
	Comment 14 • 8 years ago

This was covered by bug 1236991 right?

	blinky Reporter
	Comment 15 • 8 years ago

Pushlog for fix range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7922c7e1a69eb117431de3b2241a1ea1dc3fac08&tochange=1418ce4fcd0b1b589840c2282abf8c723a226446

This bug has been fixed in bug 1236991.

	:Gijs (he/him)
	Comment 16 • 8 years ago

(In reply to Neil Deakin from comment #14)
> This was covered by bug 1236991 right?

Per comment #15, yup!