Closed Bug 799900 Opened 8 years ago Closed 8 years ago

Wrong position of East Asian input method candidate box in HiDPI mode

Categories

(Core :: Widget: Cocoa, defect)

18 Branch
x86
macOS
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox18 + verified
firefox19 + verified

People

(Reporter: haozhun.jin, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

(Keywords: inputmethod)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20121009042010

Steps to reproduce:

1) Turn on "Pinyin - Simplified" under "Chinese - Simplified" in Input Sources (Keyboard Preference -> Keyboard -> Input Sources). You probably can use any other East Asian method that has a candidate box instead of "Pinyin"
2) Click on the newly added icon to the left of "battery meter" and "date and time", and switch to "Pinyin - Simplified"
3) Click on any text box inside FireFox, and try to type.


Actual results:

The candidate box is incorrectly positioned. It's far away from where I'm typing.
It looks like it's coordinate is (2x, 2y) relative to the top-left corner, where (x,y) is the correct position.


Expected results:

It should be placed next to where I am typing.
This screenshot shows that when I type in a textbox farther from the top-left corner of the Firefox window (compared to the first screen shot), the difference between the candidate box and where I'm typing is farther away.
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
I'm sorry. The file name and description of the two screenshots attached should be swapped. And it seems like I can't modify my comments or change files I have uploaded.
Keywords: inputmethod
I've confirmed this with both the "Pinyin - Simplified" and the "Kotoeri - Hiragana" input methods.  Though (interestingly) the candidate box for the Kotoeri input method isn't offset nearly as far as the one for "Pinyin - Simplified".

The problem doesn't happen if you turn off HiDPI support and restart the browser.  (Do this by setting gfx.hidpi.enabled to -1 in about:config.)

I tested with today's mozilla-central nightly (19 branch) on OS X 10.7.5.  The bug should also happen on the 18 branch (aurora), since it also has HiDPI support turned on.

I think this is a bad UI bug, and should block doing a release with HiDPI support turned on.  I'll get to work on it as soon as I can (in the next few days).
Assignee: nobody → smichaud
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → major
With this patch, the IME window appears at the proper position in my (brief) testing. Tryserver build in progress at https://tbpl.mozilla.org/?tree=Try&rev=e85dd276ee16.
Attachment #669993 - Flags: review?(smichaud)
I feel great that a bug I reported is handled in such a timely fashion. Thank you for your great work!
Comment on attachment 669993 [details] [diff] [review]
[HiDPI] account for device-pixel scaling for IME window position.

Looks good, and also works for me in my tests.
Attachment #669993 - Flags: review?(smichaud) → review+
Assignee: smichaud → jfkthame
(In reply to comment #5)

You're most welcome :-)

It helped that what you reported was a really bad bug.
Comment on attachment 669993 [details] [diff] [review]
[HiDPI] account for device-pixel scaling for IME window position.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:
Attachment #669993 - Flags: approval-mozilla-aurora?
[Approval Request Comment]
Bug caused by (feature/regressing bug #): 674373 (HiDPI support)

User impact if declined: East Asian users with Retina display will see IME input windows severely misplaced

Testing completed (on m-c, etc.): patch is now on inbound; confirmed as fixing the bug in local & tryserver builds

Risk to taking this patch (and alternatives if risky): minimal - patch only touches OS X code, and has no effect except in HiDPI mode

String or UUID changes made by this patch: none
Attachment #669993 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/019cfa68404a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Steven, could you please give me more details in how to reproduce the initial problem? 

I was trying to verify this on Firefox 18 beta and I followed all the steps given in the Description on a mozilla-central from 2012-10-09, but the candidate box was still in the right position.
I just had no problem reproducing this using the 2012-10-10 nightly.

When using "Piyin - Simplified" (or "Pinyin - Traditional") you need to type a real word in Chinese to see a candidate box.  Try typing "zhong".
Attached image Screenshot
I still can't reproduce the initial issue on my mini Mac 10.7.5 or 10.8.2.

I followed the STR:
1. Keyboard -> Input Sources -> selected Chinese - Simplified
2. In the menu bar selected Pinyin - Simplified 
3. Launched the nightly 2012-10-10 en-US
4. Typed “zhong” in a text box.
   The candidate box is placed next to where I'm typing - please see screenshot.

Steven, did you used a localized build? Do you have any thoughts in why can't I reproduce the problem?
Does your Mac mini have a HiDPI display? Note that this was specifically a hidpi-mode bug; you'll need a Retina MacBook or other hidpi display to reproduce it.
> Steven, did you used a localized build?

No, I used the standard en-US build.

> Do you have any thoughts in why can't I reproduce the problem?

I'll bet Jonathan's right, and that you're not testing with an HiDPI display.
> I'll bet Jonathan's right, and that you're not testing with an HiDPI display.

Steve actually don't need to bet. If you take a screenshot using the built-in snapshot tool on a retina display, the image will be the same as the actual resolution of the display. But Simona's snapshot is 1920*1080, which proves that it's not a HiDPI display.
Thanks guys for all the support, you are right I don't have HiDPI display.

Haozhun, could you please check that this is fixed on the latest Firefox 18 beta?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0b3-candidates/build1/mac/
(In reply to Simona B [QA] from comment #19)
> Thanks guys for all the support, you are right I don't have HiDPI display.
> 
> Haozhun, could you please check that this is fixed on the latest Firefox 18
> beta?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.0b3-candidates/
> build1/mac/

Yes, it is fixed on the lasted beta.
Thanks Haozhun!

Based on Comment 20 - setting the tracking flag for Firefox 18 to Verified.
Keywords: verifyme
Haozhun, can you please confirm this remains fixed with the latest Firefox 19 Beta?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #22)
> Haozhun, can you please confirm this remains fixed with the latest Firefox
> 19 Beta?

Yes. This bug remains fixed with the latest Firefox 19 beta.
Thank you very much, Haozhun.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Depends on: 899430
You need to log in before you can comment on or make changes to this bug.