1270985 - Mouse cursor no longer hides when keys are pressed

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Erik Rose [:erik][:erikrose]]

As of a recent version of Developer Edition, the mouse cursor no longer hides when keys are pressed. For example, this used to work:

1. Visit a long page.
2. Press the down arrow key to scroll.
3. The mouse cursor hides ("obscures" in Mac parlance) until the mouse is moved.

Now, instead of #3, the cursor remains visible all the time, blocking part of the page.

Comment 1

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi Erik,

I've managed to reproduce this issue on Windows 7 x32 using the latest FF release(46.0.1) and latest Nightly version(49.0a1). I'm not sure if this is an intentional change or not, so I tried to bisect this bug in order to find out where did it change. I went back as far as Firefox 5 and this issue is still reproducible. Could you please point out that is the last version on which this worked correctly?

Thanks,
Paul.

Comment 2

[Erik Rose [:erik][:erikrose]]

I don't know about Windows, but it works correctly on the Mac on 47.0b8. (I don't think Windows does the cursor-hiding thing in general.)

Comment 3

[Erik Rose [:erik][:erikrose]]

I narrowed it down to the exact version of Aurora it appears on (Aurora being where I originally noticed the bug). The first appearance of the bug is in the 4/26 build: https://ftp.mozilla.org/pub/firefox/nightly/2016/04/2016-04-26-00-41-07-mozilla-aurora/firefox-48.0a2.en-US.mac.dmg.

Comment 4

[Ciprian Muresan [:cmuresan], Ecosystem QA]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0

I have successfully reproduced this on the latest Nightly (49.0a1, Build ID 20160606030219), but not on the latest Firefox release on Mac OS 10.11.

Last good revision: 29022393615224517283b16adae938128f75e27b
First bad revision: eb7c36e2ef5d48262bc8566da9ea37623e7d0883
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=29022393615224517283b16adae938128f75e27b&tochange=eb7c36e2ef5d48262bc8566da9ea37623e7d0883

Any idea what might have caused this?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, this is a simple mistake. Taking this.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=eba357017354

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

[Tracking Requested - why for this release]: Simple regression of bug 1137563. We should take this because of very low risk fix.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1270985 Hide mouse cursor in native keydown event handler if Command key isn't pressed

Currently, TextInputHandler::DispatchEvent() isn't used for WidgetKeyboardEvent nor WidgetCompositionEvent since TextEventDispatcher directly uses nsIWidget::DispatchEvent().  Therefore, old code hiding mouse cursor at dispatching eKeyPress event is never run in current mozilla-central since TextInputHandler dispatches eKeyPress events via TextEventDispatcher.

Additionally, it's not enough to hide mouse cursor only when widget dispatches eKeyPress events because if IME starts composition, eKeyPress event won't be fired until finishing the composition. So, I think that we should hide mouse cursor at receiving native keydown events.  The event handler receives keydown events before IME handles them.  Additionally, modifier key events which won't cause eKeyPress events are not using native keydown event handler, fortunately.  So, I believe that it's the best place to do it.

Review commit: https://reviewboard.mozilla.org/r/58448/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/58448/

Comment 9

[Makoto Kato [:m_kato]]

Comment on attachment 8761113 [details]
Bug 1270985 Hide mouse cursor in native keydown event handler if Command key isn't pressed

https://reviewboard.mozilla.org/r/58448/#review55324

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/46de82827435
Hide mouse cursor in native keydown event handler if Command key isn't pressed r=m_kato

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/46de82827435

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8761113 [details]
Bug 1270985 Hide mouse cursor in native keydown event handler if Command key isn't pressed

Approval Request Comment
[Feature/regressing bug #]: Regression of bug 1137563
[User impact if declined]: The mouse cursor is never hidden by any keyboard operation (it should be hidden until next mousemove event).
[Describe test coverage new/current, TreeHerder]: Landed on m-c.
[Risks and why]: Low. Before bug 1137563, we hide mouse cursor at dispatching keypress events.  However, the approach isn't available after it since keypress events are fired by another XP level class (TextEventDispatcher) automatically. Therefore, this patch makes mouse cursor hidden at receiving native key events. See the comment in the patch when the mouse cursor is hidden by this new approach.
[String/UUID change made/needed]: Nothing.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8761113 [details]
Bug 1270985 Hide mouse cursor in native keydown event handler if Command key isn't pressed

Recent regression, looks like a simple fix, let's uplift this to aurora and beta.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this regressed in 48. It would be good to verify the fix in beta, once it lands.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/804b78a09df7

Comment 16

[Carsten Book [:Tomcat]]

 https://hg.mozilla.org/releases/mozilla-beta/rev/fb2bd3009fd4

Comment 17

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I investigated this issue on 
- 48.0b2 build2 (20160620091522)
- latest Aurora 49.0a2 (2016-06-23)
- latest Nightly 50.0a1 (2016-06-23)
using Mac OS X 10.11. 
Excepting 48.0b2 build2, the fix landed and it works as expected. Still, there is one thing that needs clarification: during the testing, I used a Windows particular keyboard and there are keys (like Alt, Shift, Caps Lock and Windows) that don't cause the cursor hiding. Is this intended or not?  
Thank you in advance!
Note: I will continue investigating the beta build, once the fix will land.

Comment 18

[Erik Rose [:erik][:erikrose]]

That is intended: modifier keys never trigger cursor obscuring, likely because they don't output characters that the mouse cursor might obscure.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Erik Rose [:erik][:erikrose] from comment #18)
> That is intended: modifier keys never trigger cursor obscuring, likely
> because they don't output characters that the mouse cursor might obscure.

Exactly. And also Cmd+Foo doesn't cause hiding the mouse cursor.

Comment 20

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Thank you, :erik and :masayuki!
Based on previous comments, I will set the proper tracking and status flags.

Comment 21

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Hello! I verified again this issue on 48.ob4 build1 (20160627144420) using 
- Mac OS X 10.11.1
- Mac OS X 10.10.5
The fix looks good and I found no misbehavior. I set the corresponding flag.