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

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[haozhun.jin]

Attachment: First_screenshot_showing_mispositioned_candidate_box.png

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.

Comment 1

[haozhun.jin]

Attachment: Another_screenshot_showing_candidate_box_farther_away.png

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.

Comment 2

[haozhun.jin]

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.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

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

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: [HiDPI] account for device-pixel scaling for IME window position.

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.

Comment 5

[haozhun.jin]

I feel great that a bug I reported is handled in such a timely fashion. Thank you for your great work!

Comment 6

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #5)

You're most welcome :-)

It helped that what you reported was a really bad bug.

Comment 8

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/019cfa68404a

Comment 9

[Jonathan Kew [:jfkthame]]

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:

Comment 10

[Jonathan Kew [:jfkthame]]

[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

Comment 11

[Jonathan Kew [:jfkthame]]

Pushed to aurora, marking as fixed for FF18:
https://hg.mozilla.org/releases/mozilla-aurora/rev/16a212953a7e

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/019cfa68404a

Comment 13

[Simona Badau, Desktop QA]

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.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

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

Comment 15

[Simona Badau, Desktop QA]

Attachment: 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?

Comment 16

[Jonathan Kew [:jfkthame]]

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.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

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

Comment 18

[haozhun.jin]

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

Comment 19

[Simona Badau, Desktop QA]

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/

Comment 20

[haozhun.jin]

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

Comment 21

[Simona Badau, Desktop QA]

Thanks Haozhun!

Based on Comment 20 - setting the tracking flag for Firefox 18 to Verified.

Comment 22

[u279076]

Haozhun, can you please confirm this remains fixed with the latest Firefox 19 Beta?

Comment 23

[haozhun.jin]

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

Comment 24

[u279076]

Thank you very much, Haozhun.