New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Jul 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
RTL

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Tooltip gets direction from Chrome langauge, not element (or even page)

Reported by lani...@gmail.com, Jan 4 2009

Issue description

Chrome Version       : 1.0.154.36
URLs (if applicable) :
Other browsers tested: IE7, Firefox 3, Safari 3.2.1
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: FAIL
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Create and open a page with the following source:
<html><body>
<span dir=rtl style="background-color:Red" title="שלום!">Hover here!</span>
<span style="background-color:Blue" title="Hi!">And now here!</span>
</body></html>

2. Hover over the red span. With Chrome's language set to English, the
tooltip reads (visually) "שלום!". With Chrome's language set to Hebrew, the
tooltip reads (visually) "!שלום" (which is what you want to be).

3. Hover over the blue span. With Chrome's language set to English, the
tooltip reads (visually) "Hi!". With Chrome's language set to Hebrew, the
tooltip reads (visually) "!Hi".


What is the expected result?
The directionality for the tooltip should be taken from the element on
which it is declared, as is the case in IE7 and FF3. Arguably - but less
usefully - it could also be taken from the page's directionality (body
element). Taking it from the browser's language, as is the case currently,
is useless.


What happens instead?
The tooltip's directionality is taken from the browser language. This
results in English tooltips being garbled in a Hebrew Chrome and Hebrew
tooltips being garbled in an English Chrome. There is no workaround. Using
Unicode BiDi formatting characters (LRE, RLE, PDF) in the tooltip text only
works if Windows is configured to have complex script support, which is not
the case for the vast majority of machines. 

Please provide any additional information below. Attach a screenshot if
possible.

 
chrometooltip.PNG
16.8 KB View Download
Labels: -Area-Misc Area-BrowserUI RTL I18N
Test case that specifies the content-type:

<html>
<head>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=utf-8">
</head>
<body>
<span dir=rtl style="background-color:Red" title="שלום!">Hover here!</span>
<span style="background-color:Blue" title="Hi!">And now here!</span>
</body></html>

Status: Available
Tested in the following Browsers:
Safari on OS X: OK
Safari on Windows: Exhibits bug.
Chrome: Exhibits bug.

Comment 4 by xji@chromium.org, Jan 22 2009

Status: Assigned

Comment 5 by xji@chromium.org, Feb 26 2009

The fix probably should come from both Webkit and Chrome.
Webkit needs to populate the correct directionality for each element.
Chrome should not override a webpage element's directionality based on Chrome UI's 
directionality.

File webkit bug as:
https://bugs.webkit.org/show_bug.cgi?id=24187

Comment 6 by xji@chromium.org, Jun 24 2009

Status: Started

Comment 7 by bugdro...@gmail.com, Jul 22 2009

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21266 

------------------------------------------------------------------------
r21266 | xji@chromium.org | 2009-07-21 22:56:24 -0700 (Tue, 21 Jul 2009) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/chrome_client_impl.cc?r1=21266&r2=21265
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/chrome_client_impl.h?r1=21266&r2=21265

This CL fixes  issue 5996 : Tooltip gets direction from Chrome langauge, not element (or even page)

The related webkit bug is
https://bugs.webkit.org/show_bug.cgi?id=24187

After webkit passes both the title string and its directionality to its client, Chrome will force the title to be displayed in correct directionality using Unicode Control characters.

BUG= http://crbug.com/5996 
TEST=In both English Chrome and Hebrew Chrome
1. open the test case in  http://crbug.com/5996  comment #1 
2. hover over the red span, tooltip should be displayed as RTL in both English Chrome and Hebrew Chrome.
3. hover over the blue span, tooltip should be displayed as LTR in both English Chrome and Hebrew Chrome.

Review URL: http://codereview.chromium.org/147240
------------------------------------------------------------------------

Comment 8 by prog...@gmail.com, Jul 22 2009

xiaomei, can this change in webkit be related to the problematic webkit merge in Issue 
17176 ?

Comment 9 by xji@chromium.org, Jul 22 2009

Status: Fixed
fixed in r21266.

progame: Thanks for identifying and letting me know the other  issue 17176 . Yes, webkit 
change was the root cause. I've updated  issue 17176 .
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21353 

------------------------------------------------------------------------
r21353 | xji@chromium.org | 2009-07-22 17:19:52 -0700 (Wed, 22 Jul 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/chrome_client_impl.cc?r1=21353&r2=21352

This CL fixes  issue 17468  - Regression: Extra white rectangle showing when mouse hovering on every web page

Should check tooltip text against empty before adding Unicode Marks for directionality.

BUG= http://crbug.com/17468 
BUG= http://crbug.com/17176 
BUG= http://crbug.com/5996 
TEST= open a webpage, mouse over plain text area, empty square should not show up as tooltip. 
Review URL: http://codereview.chromium.org/159222
------------------------------------------------------------------------

Comment 11 by xji@chromium.org, Jul 23 2009

CL in comment #10 fix regression  issue 17468  (empty tooltip showup) caused by CL in 
comment #7.

Comment 12 by lani...@gmail.com, Jul 23 2009

I am not sure that I have seen the final version of the change, but I have a concern, 
if the latest logic is still to always wrap in either LRE or RLE (and then PDF). It 
would be best not to wrap when the intended directionality of the title is the same as 
the browser's directionality (and the wrapping simply isn't needed). My concern is that 
the LRE and PDF characters could be displayed as funny little graphics characters on 
Windows systems without RTL script support enabled (i.e. 99% of the Windows systems in 
the world - but probably not the systems of the developers on this thread! :-) for your 
normal garden variety purely LTR pages.

Comment 13 by xji@chromium.org, Jul 23 2009

laninva, I tested in windows XP by unchecking "install files for complex script and 
right-to-left languages (including Thai)" and restarting the system, which should 
uninstall the RTL scripts, the above test works as expected, without funny little 
graphics displayed as LRE/PDF.

Please let me know if you see problems.

Comment 14 by xji@chromium.org, Jul 23 2009

Xiaolu tested in Windows Vista without RTL input method enabled, and there is no 
funny characters displayed.

I do not know how do we distinguish "when the intended directionality of the title is 
the same as the browser's directionality" from "directionality of the title is from 
element's". And I did not find clear specification from W3C about the title 
attribute's directionality. 

If there is problem, one thing we could do is to use IsRTLKeyboardLayoutInstalled() 
introduced by Hironori when he implemented shift-ctrl keyboard operation to add those 
Unicode marks only when RTL keyboard layout is installed in Windows.
Yes, you must check that kind of thing to avoid causing problems; see  bug 17468 .  A 
significant number of users have reported regressions here.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21654 

------------------------------------------------------------------------
r21654 | laforge@chromium.org | 2009-07-27 10:21:05 -0700 (Mon, 27 Jul 2009) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/webkit/glue/chrome_client_impl.cc?r1=21654&r2=21653
   M http://src.chromium.org/viewvc/chrome/branches/195/src/webkit/glue/chrome_client_impl.h?r1=21654&r2=21653

Merge 21266 - This CL fixes  issue 5996 : Tooltip gets direction from Chrome langauge, not element (or even page)

The related webkit bug is
https://bugs.webkit.org/show_bug.cgi?id=24187

After webkit passes both the title string and its directionality to its client, Chrome will force the title to be displayed in correct directionality using Unicode Control characters.

BUG= http://crbug.com/5996 
TEST=In both English Chrome and Hebrew Chrome
1. open the test case in  http://crbug.com/5996  comment #1 
2. hover over the red span, tooltip should be displayed as RTL in both English Chrome and Hebrew Chrome.
3. hover over the blue span, tooltip should be displayed as LTR in both English Chrome and Hebrew Chrome.

Review URL: http://codereview.chromium.org/147240

TBR=xji@chromium.org

Review URL: http://codereview.chromium.org/160169
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21689 

------------------------------------------------------------------------
r21689 | laforge@chromium.org | 2009-07-27 13:36:32 -0700 (Mon, 27 Jul 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/webkit/glue/chrome_client_impl.cc?r1=21689&r2=21688

Merge 21353 - This CL fixes  issue 17468   Regression: Extra white rectangle showing when mouse hovering on every web page

Should check tooltip text against empty before adding Unicode Marks for directionality.

BUG= http://crbug.com/17468 
BUG= http://crbug.com/17176 
BUG= http://crbug.com/5996 
TEST= open a webpage, mouse over plain text area, empty square should not show up as tooltip. 
Review URL: http://codereview.chromium.org/159222

TBR=xji@chromium.org

Review URL: http://codereview.chromium.org/160189
------------------------------------------------------------------------

Status: Verified
Verified on build 3.0.195.3 (Official Build 21825), fixed.
Labels: -I18N bulkmove Feature-I18N
Chrome Version       : 1.0.154.36
URLs (if applicable) :
Other browsers tested: IE7, Firefox 3, Safari 3.2.1
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: FAIL
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Create and open a page with the following source:
&lt;html&gt;&lt;body&gt;
&lt;span dir=rtl style=&quot;background-color:Red&quot; title=&quot;שלום!&quot;&gt;Hover here!&lt;/span&gt;
&lt;span style=&quot;background-color:Blue&quot; title=&quot;Hi!&quot;&gt;And now here!&lt;/span&gt;
&lt;/body&gt;&lt;/html&gt;

2. Hover over the red span. With Chrome's language set to English, the
tooltip reads (visually) &quot;שלום!&quot;. With Chrome's language set to Hebrew, the
tooltip reads (visually) &quot;!שלום&quot; (which is what you want to be).

3. Hover over the blue span. With Chrome's language set to English, the
tooltip reads (visually) &quot;Hi!&quot;. With Chrome's language set to Hebrew, the
tooltip reads (visually) &quot;!Hi&quot;.


What is the expected result?
The directionality for the tooltip should be taken from the element on
which it is declared, as is the case in IE7 and FF3. Arguably - but less
usefully - it could also be taken from the page's directionality (body
element). Taking it from the browser's language, as is the case currently,
is useless.


What happens instead?
The tooltip's directionality is taken from the browser language. This
results in English tooltips being garbled in a Hebrew Chrome and Hebrew
tooltips being garbled in an English Chrome. There is no workaround. Using
Unicode BiDi formatting characters (LRE, RLE, PDF) in the tooltip text only
works if Windows is configured to have complex script support, which is not
the case for the vast majority of machines. 

Please provide any additional information below. Attach a screenshot if
possible.
The bug is present in Chrome 11.0.696.71.

tooltip-dir.PNG
20.2 KB View Download
Project Member

Comment 21 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Feature-I18N Cr-UI-I18N
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 20 2013

Labels: -Cr-UI-I18N Cr-UI-Internationalization

Sign in to add a comment