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.

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.

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

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.

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?

Ah, this is a simple mistake. Taking this.

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

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

Pushed by masayuki@d-toybox.com: 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 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 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.

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

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

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.

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

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

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

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.