Closed Bug 1016200 Opened 10 years ago Closed 10 years ago

Single click stop working in web content, require double click

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla33
Tracking Flags:
Tracking Status
firefox29 --- unaffected
firefox30 --- unaffected
firefox31 --- unaffected
firefox32 + fixed
firefox33 --- fixed

People

(Reporter: flod, Assigned: smichaud)

References

Details

(Keywords: regression)

Attachments

(1 file)

Possible fix (supplemental fix)
(deleted), patch
spohl
: review+
lmandel
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
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).
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.
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.
gps talked about something very similar on #fx-team, iirc.
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.
Bug 996848 looks very suspicious.
Blocks: 996848
Hardware: x86 → All
Component: General → Widget: Cocoa
Product: Firefox → Core
I experienced this the other day with the 2014-05-23 Nightly. I made it go away by disabling the SQLite Manager add-on.
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. :/
> 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.
Assignee: nobody → smichaud
Blocks: 1013852
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.
No longer blocks: 1013852
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
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.
I'm still experiencing this issue on OSX with 33.0a1 (2014-06-10)
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.
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.
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.
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.
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.
jryans:  Are plugins involved in some way (as they might be in Brian's case)?
(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.
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.
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/smichaud@pobox.com-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.
(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/smichaud@pobox.com-
> 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.
Sorry I just noticed the build now, I just installed it and will try it and let you know.
The problem seems gone with that build.
bbondy and jryans:

Here's a debug logging build for you to try:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-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"
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
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.
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.
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.
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
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 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.
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.
> 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.
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.
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).
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.
Flags: needinfo?(netzen)
Flags: needinfo?(jryans)
Flags: needinfo?(felipc)
I've been using that build and I haven't seen the problem with that build.
Flags: needinfo?(netzen)
I've also been using it, and so far have seen no issues.
Flags: needinfo?(jryans)
Thanks, bbondy and jryans, for your reports.  And for your tests!

I'll try to get my patch reviewed and landed early next week.
Attachment #8446193 - Flags: review?(spohl.mozilla.bugs)
I haven't used the try-build daily but I tried it with my testcase and it worked for me
Flags: needinfo?(felipc)
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.
Attachment #8446193 - Flags: review?(spohl.mozilla.bugs) → review+
> 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 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
https://hg.mozilla.org/mozilla-central/rev/5f7e8306f31f
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: mozilla32 → mozilla33
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?
Flags: needinfo?(smichaud)
> 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.
Flags: needinfo?(smichaud)
Aurora is currently the 32 branch.
Correct - I've got my numbers screwy. Must be the heat. :)
status-firefox32: fixed → affected
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.
status-firefox33: --- → fixed
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
Attachment #8446193 - Flags: approval-mozilla-aurora?
Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Aurora+
Attachment #8446193 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8446193 [details] [diff] [review]
Possible fix (supplemental fix)

Landed on mozilla-aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/57da94b8da21
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: