1016200 - Single click stop working in web content, require double click

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Francesco Lodolo [:flod]]

Still not sure how to reproduce it, but it keeps coming back in the last days (running Nightly on OS X): all of a sudden, single clicks in web pages stop working.

I excluded a device problem (Magic Trackpad), since it happens also with a standard mouse. Single click on UI work fine, double clicks to select in text areas as well, in web content I'm forced to use double clicks to open a link.

Right now I'm in this situation, and I already know that it will go away restarting the browser (I restart it daily to apply updates).

List of add-ons is pretty limited and hasn't changed significantly in the last period (only addition Nimbus Screen Capture).

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

I definitely have the same problems. When opening another application, closing its window and then clicking Nightly to re-focus it it sometimes doesn't accept that. I haven't found a good way to reproduce yet but it happens a few times daily.

Comment 2

[Francesco Lodolo [:flod]]

Another weird thing: this time I didn't restart the browser because I wanted to file this bug, links started working again after a few minutes.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

gps talked about something very similar on #fx-team, iirc.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Putting the browser under load makes it a lot more reproducible. Executing this snippet in the web console is enough:

setInterval(function () { for (var i=0; i<1000; i++) console.log("foobar"); }, 0);

This exacerbates the problem to a point where you have to click multiple times to actually make Nightly gain focus.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=20ca234fd62b&tochange=4b6d63b05a0a

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

Bug 996848 looks very suspicious.

Comment 7

[Gregory Szorc [:gps]]

I experienced this the other day with the 2014-05-23 Nightly. I made it go away by disabling the SQLite Manager add-on.

Comment 8

[Justin Dolske [:Dolske]]

Has this been happening for a while? I started noticing something like this after having my MBP trackpad replaced last year, and assumed it was just something quirky with my hardware/OS. :/

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> Has this been happening for a while?

The patch for bug 996848 has only been in the tree (on the 32 branch) since the 2014-05-13 m-c nightly.

So you might be seeing something else.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

I've got a possible fix for this at bug 1013852.

I've started a tryserver build, which should eventually be available at bug 1013852 comment #30.

Please try it out.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

This should be fixed by my patch for bug 1013852, which just appeared in a m-c nightly -- today's.  If not, please reopen this bug.

Comment 12

[Francesco Lodolo [:flod]]

Things are definitely better, but I got the same error this morning with yesterday's nightly. I'll reopen the bug if I see it again.

Comment 13

[Brian R. Bondy [:bbondy]]

I'm still experiencing this issue on OSX with 33.0a1 (2014-06-10)

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Brian, please provide *much* more info :-)

Please say exactly, and in great detail, how you've been able to reproduce this bug, even if these STR aren't really reproducible.

Comment 15

[Brian R. Bondy [:bbondy]]

Unfortunately it's not consistently reproducible, but as I use Firefox Nightly day to day on OSX, I experience it every day.  I haven't been able to narrow down on a specific set of steps. But once the tab is in 'double-click to do anything in content' mode, it seems to stay that way. 

Clicking on chrome (tabs headers, buttons, dev tools) always works with a single click to select things.

When I do reproduce in content, I have to click twice to focus in an edit field, click a link, click a checkbox, 

I'm not certain how long I've been experiencing the issue, but I think around 2-3 weeks.

I'll try to gather more info next time I reproduce it by trying things out.

Comment 16

[Brian R. Bondy [:bbondy]]

OK I am reproducing it right now so have a bit more info for you. 
It just started happening, I've had the browser session open for about 5 hours.
It started happening on youtube. 

I can change tabs easily with 1 click, but any content I try to click on requires 2 clicks.
Now that it's reproduced, I can change to any tab and I have to double-click on everything in content for it to single-click. So it's not specific to only a single tab. It seems like while I'm in this broken state, it is broken in all tabs.

... 2 minutes later...

While I was typing in this comment the problem went away, and is now gone in all tabs. I can again focus in edit boxes, and click links with a single click.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Thanks, Brian.

At some point I'm going to give this a full-court press, to see if I can manage to reproduce it myself.  Probably sometime next week.

Do let us know if you find out more.

By the way, would it be fair to say that the problem only happens when/after you've clicked on a plugin to focus it?  If so, what you're seeing may turn out to be unrelated to this bug.

Comment 18

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Just thought I'd note a workaround of sorts...  When this issue occurs for me, I can get it to go away for a time by Cmd+Tab switching away from Firefox and then back again.  After this, I can single-click content once more (as expected).

Still haven't found a reliable way to cause double-click mode to be triggered yet.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

jryans:  Are plugins involved in some way (as they might be in Brian's case)?

Comment 20

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Steven Michaud from comment #19)
> jryans:  Are plugins involved in some way (as they might be in Brian's case)?

I don't recall actively interacting with any plugins, but I will try to watch out for that.  Though, it seems unlikely to me, because I currently have every plugin set to either "Ask to Activate" or "Never Activate", and I avoid interacting with plugins whenever I can manage it.  I no longer have Flash installed at all, so that eliminates the most common usages of plugins I am likely to encounter I would think.

Anyway, I'll look out for that.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

Thanks, jryans, for the info.  It sounds like plugins *aren't* involved -- at least not directly.  But our plugin blocking infrastructure still might be, somehow.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

bbondy and jryans:

Here's a tryserver build with my patch for bug 996848 and all related patches backed out (but otherwise based on current trunk code):

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f370677f7940/try-macosx64/firefox-33.0a1.en-US.mac.dmg

Please try it for a couple of days, to check if you still see the problem you've reported.

Comment 23

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Steven Michaud from comment #22)
> bbondy and jryans:
> 
> Here's a tryserver build with my patch for bug 996848 and all related
> patches backed out (but otherwise based on current trunk code):
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> f370677f7940/try-macosx64/firefox-33.0a1.en-US.mac.dmg
> 
> Please try it for a couple of days, to check if you still see the problem
> you've reported.

I've now been using this build since you posted it a few days ago, and I haven't seen the double-click issue so far, so that may pin the blame on the patches you backed out to produce it.

I am happy to test any other builds, maybe with debug log files or whatever, to help pinpoint the cause.

Comment 24

[Brian R. Bondy [:bbondy]]

Sorry I just noticed the build now, I just installed it and will try it and let you know.

Comment 25

[Brian R. Bondy [:bbondy]]

The problem seems gone with that build.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

bbondy and jryans:

Here's a debug logging build for you to try:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-52003d367752/try-macosx64/firefox-33.0a1.en-US.mac.dmg

https://tbpl.mozilla.org/?tree=Try&rev=52003d367752

Please test with this build until the bug starts happening.  Then look in the console (/var/log/system.log) for anything interesting in the few minutes before the bug started happening ... and/or that keeps happening as the bug is happening.

My debug logging build logs messages with this format:
"nsAppShell::ProcessNextNativeEvent(!aMayWait): event class %s, kind %u"

Comment 27

[Brian R. Bondy [:bbondy]]

Happened to me a couple times over the weekend. Both times it was only for about 30 seconds though.
It seems like when I load this bugzilla page and start clicking in the fields it eventually goes away.

Here's the log:
Jun 22 06:58:53 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 06:58:57 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 14:19:02 Brians-MacBook-Pro.local firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 4
Jun 22 14:38:49 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 4
Jun 22 15:03:46 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:08:00 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:08:01 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:09:18 brians-mbp firefox[10326]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:14:16 brians-mbp firefox[11261]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:15:54 brians-mbp firefox[11270]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:18:38 brians-mbp firefox[11270]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:18:41 brians-mbp firefox[11284]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:19:09 brians-mbp firefox[11284]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:19:24 brians-mbp firefox[11294]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:21:09 brians-mbp firefox[11310]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:21:39 brians-mbp firefox[11310]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 22 15:21:41 brians-mbp firefox[11316]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 15:23:45 brians-mbp firefox[11339]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103
Jun 22 21:08:47 brians-mbp firefox[250]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class eppc, kind 1
Jun 22 21:09:23 brians-mbp firefox[250]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21

Comment 29

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I've been using the logging build since you posted it, but so far I haven't seen the issue happen yet.  I would have expected to see it at least once by now...  Will update if I have more info to share.

Comment 30

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Here's my log from today:

Jun 23 18:19:56 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 23 18:20:08 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 23 18:20:52 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21
Jun 23 22:13:25 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 3
Jun 23 22:18:53 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 3
Jun 23 22:58:53 vin.local firefox[69630]: nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21

I did see the problem occur just now before copying this, so the last line above is closest to the problem occurring.

Comment 31

[:Felipe Gomes (needinfo for replies!)]

I've found some possible STR. I'm gonna give absurd details because it's not clear what matters here, so here it goes:

- I have the "Hot Corners" feature enabled, and the top-left corner is set to "Desktop" (it moves the windows away to peek at the desktop)
- Open http://imgur.com
- Move mouse to top-left corner
- Find an image file on your desktop, and drag it
- Move mouse to top-left corner again to bring the windows back
- Drop the image file inside the imgur.com page

After this, you should be able to click the button "Start upload" (or any other button, really), but it takes two clicks to do.

Note that it doesn't reproduce easily.. But I've noticed this being the exact moment trigger where it starts happening, 2 or 3 times now.

Comment 32

[:Felipe Gomes (needinfo for replies!)]

The "X" button in the dialog from their site also works well as a testing, if you want to avoid having to upload an image every time.

Some more details:
 - the problem goes away by itself after a while
 - it is contained to a single window
 - Cmd + Click works (doesn't require a double click to open a link in a new tab, for example)
 - Clicking for text selection gets wonky: the "double click" to select a word doesn't work, but the "triple click" to select the phrase does.

I'm gonna run your try build with logging and report back

Comment 33

[Steven Michaud [:smichaud] (Retired)]

Since my patch for bug 1013852 didn't completely fix this bug, I'll reopen it.

For now I'll concentrate on identifying the events from the logs -- which presumably shouldn't be processed while !aMayWait.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21

After some digging around, I discovered that this (undocumented) event is sent when, while Firefox is active, you drag something around on the desktop.  You see one event when you start dragging.  Then if you drop the object over a Firefox browser window, you see another.

Under normal circumstances, these get converted into Cocoa NSEvent objects of type "ProcessNotification" (also undocumented).

All your logs include this event.  So it's likely that good STR for this bug (the part that hasn't already been fixed) includes dragging something while Firefox is active.

Comment 35

[Steven Michaud [:smichaud] (Retired)]

Felipe, your STR from comment #31 works for me (I see the bug) about one time in 5.

Every time I do see it (using my debug logging build), I get exactly one of the following in the system log:

> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class cgs , kind 21

Though I often see one of these messages without seeing the bug.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 3
> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class macs, kind 4

These are documented events of class kEventClassSystem:
kEventSystemDisplaysAsleep and kEventSystemDisplaysAwake

> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class eppc, kind 1

These are Apple Events -- for example the kAEReopenApplication event that the OS sends to FF every time you click on its Dock icon.

> nsAppShell::ProcessNextNativeEvent(!aMayWait): event class appl, kind 103

These are events of class kEventClassApplication, but of an undocumented kind.

As best I can tell, events of class kEventClassSystem and Apple Events never get turned into Cocoa events (NSEvent objects).  So we don't need to worry about them getting processed in ProcessNextNativeEvent() when !aMayWait.

Most events of class kEventClassApplication don't get turned into Cocoa events, either -- including events of kind 103 (which is undocumented).  But I've observed that a couple of kinds of these events (kEventAppActivated and kEventAppDeactivated) *do* get changed into Cocoa events.  And there may be others I've missed.  So it's probably best to not process these events in ProcessNextNativeEvent() while !aMayWait.

Comment 37

[Steven Michaud [:smichaud] (Retired)]

As for events of (undocumented) class 'cgs ', we've observed (in comment #34) that some of these get translated into Cocoa events.  And there may be others I haven't noticed.

The only 'cgs ' events I *know* are "safe" to process when !aMayWait are the "fake" events created and sent by nsAppShell::ProcessGeckoEvents() (because they don't require any processing).  When/if these get translated to Cocoa events they become NSEvents of kind NSApplicationDefined.  And I'm quite sure Firefox receives no other event of this kind.

So it's probably best to refuse to process any 'cgs ' event in ProcessNextNativeEvent(!aMayWait) except those of kind NSApplicationDefined.

Comment 38

[Steven Michaud [:smichaud] (Retired)]

I'll post a patch shortly.  But first I want to get a tryserver build for people to test (and to see the results of the automated tests run on tryserver).

Comment 39

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible fix (supplemental fix)

Here's my patch.

Here's the tryserver build.  Please test it!
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5681694b194c/try-macosx64/firefox-33.0a1.en-US.mac.dmg

And here's where the test results will eventually come in:
https://tbpl.mozilla.org/?tree=Try&rev=5681694b194c

Comment 40

[Steven Michaud [:smichaud] (Retired)]

If you guys haven't already started testing with my tryserver build from comment #39, please do so.  And please report back with your results.

Comment 41

[Brian R. Bondy [:bbondy]]

I've been using that build and I haven't seen the problem with that build.

Comment 42

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I've also been using it, and so far have seen no issues.

Comment 43

[Steven Michaud [:smichaud] (Retired)]

Thanks, bbondy and jryans, for your reports.  And for your tests!

I'll try to get my patch reviewed and landed early next week.

Comment 45

[:Felipe Gomes (needinfo for replies!)]

I haven't used the try-build daily but I tried it with my testcase and it worked for me

Comment 46

[Stephen A Pohl [:spohl]]

Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Review of attachment 8446193 [details] [diff] [review]:
-----------------------------------------------------------------

I couldn't find a bug for the xpcshell failure in the try run from comment 39, but it looks unrelated to this patch. The patch looks good to me, thanks!

::: widget/cocoa/nsAppShell.mm
@@ +575,3 @@
>        bool osCocoaEvent =
> +        ((eventClass == 'appl') ||
> +        ((eventClass == 'cgs ') && (eventKind != NSApplicationDefined)));

nit: we might want to indent this line by one space to make the parentheses easier to read, or drop the outermost parenthesis.

Comment 47

[Steven Michaud [:smichaud] (Retired)]

> we might want to indent this line by one space to make the parentheses easier to read

I'll indent the second line by one space.

Comment 48

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Landed on mozilla-inbound (with Stephen's recommended change):
https://hg.mozilla.org/integration/mozilla-inbound/rev/5f7e8306f31f

Comment 49

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

https://hg.mozilla.org/mozilla-central/rev/5f7e8306f31f

Comment 50

[Mike Conley (:mconley) (:⚙️)]

I've been experiencing behaviour like this in Aurora (31) on multiple OS X machines. It looks as though bug 996848 isn't on the Aurora channel yet... could something else have introduced this behaviour there?

Comment 51

[Steven Michaud [:smichaud] (Retired)]

> It looks as though bug 996848 isn't on the Aurora channel yet...

It is, though.  That patch landed on "trunk" when "trunk" was the 32 branch.

Please let us know if you keep seeing this bug in tomorrow's m-c nightly or later ones.

Comment 52

[Steven Michaud [:smichaud] (Retired)]

Aurora is currently the 32 branch.

Comment 53

[Mike Conley (:mconley) (:⚙️)]

Correct - I've got my numbers screwy. Must be the heat. :)

Comment 54

[Steven Michaud [:smichaud] (Retired)]

In a few days, if all goes well, I'll ask for this patch to be uplifted to the 32 branch, where this bug is still unfixed.

Comment 55

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

(Following up comment #54)

Approval Request Comment
[Feature/regressing bug #]: 996848
[User impact if declined]: Users who drag objects over FF will see an annoying bug intermittently
[Describe test coverage new/current, TBPL]: Baked on m-c for last week with no reported problems
[Risks and why]: Low risk
[String/UUID change made/needed]: none

Comment 56

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Aurora+

Comment 57

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Landed on mozilla-aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/57da94b8da21