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 1 user
Status: Fixed
Closed: Jul 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Candidate windows is shown in wrong place in Retina display
Project Member Reported by, Jul 26 2012 Back to list
Version: 22.0.1217.0 canary
OS: MacOS X 10.7.4 and 10.8

What steps will reproduce the problem?
1. open
2. enable Kotoeri
3. enter "a" + space

What is the expected output? What do you see instead?
Candidate windows is shown in wrong place in Retina display

Please use labels and text to provide additional information.

Comment 1 by, Jul 26 2012
2.3 MB View Download
Labels: hotlist-Japan
Comment 3 by, Jul 26 2012
Status: Started

Unfortunately I don't have retina mac pro, but I may find the matter of cause.
According to the documentation, we should not use deprecated APIs for coordinates calculation. 

I will change to use convertRectToBacking/convertRectToScreen instead of convertRectToBase/convertScreenToBase if possible.

Comment 4 by, Jul 26 2012
Labels: Feature-HighDPI macdpi
That's likely wrong. You want convertRect:rect toView:nil instead if convertRectToBase: is used anywhere at the moment. See!topic/chromium-dev/7kN3KagcwNg for more information.
Comment 5 by, Jul 26 2012
You don't need a retina mac to test this by the way, you only need to run OS X 10.7 (which was released long ago). See for how to test retina mode on a "normal" mac.
Comment 6 by, Jul 26 2012
Oh, thank you for good information!

I will try it!
Comment 7 by, Jul 27 2012
reassigning to horo@

He kindly take on this issue.
Comment 8 by, Jul 27 2012
Status: Assigned
Comment 9 by, Jul 27 2012
If the code change involves fixing coordinate conversion, please assign me for review.
Comment 10 by, Jul 29 2012
This cl will fix the problem.

1.4 MB View Download
1.7 MB View Download
2.2 MB View Download
1.7 MB View Download
Status: Started
Your CL also fixes the bubble that appears if you keep eg "a" pressed with a US keyboard layout in lion or mountain lion. Thanks!
Labels: Mstone-21 Merge-Requested
Karen, can we take merge this to 1180 for the m21 stable refresh? The fix is a very safe one line "well, duh" CL. (I realize the CL hasn't even landed yet, but since it just changes a coordinate computation, it's virtually impossible for it to have a stability impact).
Comment 13 by, Jul 29 2012
let's go to stable first and then we can consider it :)
Project Member Comment 14 by, Jul 29 2012
The following revision refers to this bug:

r148916 | | 2012-07-29T18:09:47.791867Z

Changed paths:

Fix the candidate window position of IME in Retina display.

BUG= 139108 
TEST=manually done

Review URL:
Fix confirmed on canary, in both lodpi and hidpi.
Comment 16 by, Jul 30 2012
Labels: -Merge-Requested Merge-Approved

Thanks horo@, nona@ and everyone!
Comment 18 Deleted
The issue is not reproducible in Mac 10.7.4 & Mac 10.8 ( Retina ) .
Build Used : 22.0.1221.0

Status: Fixed
I'll merge this to m21 once the first stable push has happened.
Project Member Comment 21 by, Aug 1 2012
Labels: -Merge-Approved merge-merged-1180
The following revision refers to this bug:

r149354 | | 2012-08-01T02:15:11.652222Z

Changed paths:

Merge 148916 - Fix the candidate window position of IME in Retina display.

BUG= 139108 
TEST=manually done

Review URL:
Review URL:
Project Member Comment 22 by, 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 23 by, Mar 10 2013
Labels: -Area-UI -Feature-TextInput -Feature-HighDPI -Mstone-21 Cr-UI Cr-UI-HighDPI M-21 Cr-UI-Input-Text-IME
Project Member Comment 24 by, Mar 14 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment