New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Menu bar becomes unresponsive when hovering Toolbar menus [M641597] #72

Closed
GoogleCodeExporter opened this Issue Aug 9, 2015 · 50 comments

Comments

Projects
None yet
3 participants
@GoogleCodeExporter
Contributor

GoogleCodeExporter commented Aug 9, 2015

* This is a startup crash or failure to start (Y/N): N

* This is a fault of JavaScript acceleration (Y/N): (Use the steps above to
find out. Do NOT report if it is not.) N

* What steps are necessary to reproduce the bug? These must be reasonably 
reliable.

If you have the Bookmarks Toolbar and/or the Web Developer Toolbar (anything 
with submenus/folders), you can hover these left and right when they are open. 
See the video below, I don't know a better way to describe this. If you do this 
for a while (about 10 times right and left), the TFF Menu bar (including the 
Apple menu) stops working until you restart TFF. Other applications are not 
affected. When I rightclick the nonworking Menu bar, I get a contextual menu 
that I should get when rightclicking a toolbar in the browser window. I made a 
reduced testcase bookmarks file with only empty folders.

* Describe your processor, computer, operating system and any special
things about your environment.

PowerBook G4 1.33 GHz (7450), 10.5.8

* Include any useful additional information, steps you have tried, etc.:

attached testcase bookmarks file.
video (how to trigger the bug): http://www.youtube.com/watch?v=l7H1Conr42U

Additional information:
Machine: PowerBook G4 1.33 GHz (7450), 10.5.8
Created new OS X user account for testing; there are no haxies installed on 
this machine
The content of the folders in the toolbar doesn't matter, they can even be empty
It doesn't matter if nanojit for chrome is enabled or not.
It also happens in TFF 4.0.2., but not in Seamonkey 2.0.x
It doesn't seem to happen on G3 with 10.4.11 (at least I was unable to trigger 
it)
It does happen reliably on G4 with 10.5 (but I don't know if it's the processor 
type or the OS)
I don't know if this is a TFF, Mozilla, or OS X bug 

Original issue reported on code.google.com by chtru...@web.de on 21 Jun 2011 at 12:57

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
So I played with this a little and I can't trigger it in 10.4.11, but your STRs 
seem clear enough, so perhaps this is 10.5-only. I'll see if I can trip it on 
the 10.5 Mac mini later, but that machine is Intel, so I don't know if Rosetta 
will be a factor. Marking Unconfirmed for now.

Original comment by classi...@floodgap.com on 21 Jun 2011 at 1:15

  • Changed state: Unconfirmed
Contributor

GoogleCodeExporter commented Aug 9, 2015

So I played with this a little and I can't trigger it in 10.4.11, but your STRs 
seem clear enough, so perhaps this is 10.5-only. I'll see if I can trip it on 
the 10.5 Mac mini later, but that machine is Intel, so I don't know if Rosetta 
will be a factor. Marking Unconfirmed for now.

Original comment by classi...@floodgap.com on 21 Jun 2011 at 1:15

  • Changed state: Unconfirmed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Some additional information I found over time.
1) The menu bar will eventually become unresponsive if the browser hasn't been 
re-started for long enough (several days). There may be a specific number of 
times you can hover the toolbar/bookmarks bar menus that adds up sooner or 
later and triggers the event when it is reached.
2) The browser doesn't have to be re-started to recover from the situation. 
It's sufficient to close all open windows.

Original comment by chtru...@web.de on 9 Aug 2011 at 10:44

Contributor

GoogleCodeExporter commented Aug 9, 2015

Some additional information I found over time.
1) The menu bar will eventually become unresponsive if the browser hasn't been 
re-started for long enough (several days). There may be a specific number of 
times you can hover the toolbar/bookmarks bar menus that adds up sooner or 
later and triggers the event when it is reached.
2) The browser doesn't have to be re-started to recover from the situation. 
It's sufficient to close all open windows.

Original comment by chtru...@web.de on 9 Aug 2011 at 10:44

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
That actually is quite helpful. I have an idea about this, but I'm going to 
defer it to 7.0. There is a 10.4-specific fix for dropdowns (issue 9 
originally) and maybe we should conditional it for 10.4 only.

Original comment by classi...@floodgap.com on 13 Aug 2011 at 11:05

  • Changed state: Accepted
  • Added labels: Priority-High
Contributor

GoogleCodeExporter commented Aug 9, 2015

That actually is quite helpful. I have an idea about this, but I'm going to 
defer it to 7.0. There is a 10.4-specific fix for dropdowns (issue 9 
originally) and maybe we should conditional it for 10.4 only.

Original comment by classi...@floodgap.com on 13 Aug 2011 at 11:05

  • Changed state: Accepted
  • Added labels: Priority-High
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Planned for 7

Original comment by classi...@floodgap.com on 30 Aug 2011 at 3:33

  • Changed state: Started
  • Added labels: Milestone-NextBeta7
Contributor

GoogleCodeExporter commented Aug 9, 2015

Planned for 7

Original comment by classi...@floodgap.com on 30 Aug 2011 at 3:33

  • Changed state: Started
  • Added labels: Milestone-NextBeta7
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
The fix in 7.0b1 doesn't seem to work. The problem is still the there.

Original comment by chtru...@web.de on 5 Sep 2011 at 10:55

Contributor

GoogleCodeExporter commented Aug 9, 2015

The fix in 7.0b1 doesn't seem to work. The problem is still the there.

Original comment by chtru...@web.de on 5 Sep 2011 at 10:55

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Do you get any crashes with it? See issue 9 for the crash signature.

Original comment by classi...@floodgap.com on 5 Sep 2011 at 2:35

Contributor

GoogleCodeExporter commented Aug 9, 2015

Do you get any crashes with it? See issue 9 for the crash signature.

Original comment by classi...@floodgap.com on 5 Sep 2011 at 2:35

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
No, the browser doesn't crash.

Original comment by chtru...@web.de on 5 Sep 2011 at 2:52

Contributor

GoogleCodeExporter commented Aug 9, 2015

No, the browser doesn't crash.

Original comment by chtru...@web.de on 5 Sep 2011 at 2:52

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
[deleted comment]
Contributor

GoogleCodeExporter commented Aug 9, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
I've seen the unresponsive menu bar issue mentioned several times on the 
Mozilla forums, going back to FF4, so this is not specific to TFF.

Original comment by amc...@gmail.com on 15 Sep 2011 at 9:45

Contributor

GoogleCodeExporter commented Aug 9, 2015

I've seen the unresponsive menu bar issue mentioned several times on the 
Mozilla forums, going back to FF4, so this is not specific to TFF.

Original comment by amc...@gmail.com on 15 Sep 2011 at 9:45

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Do you have a Mozilla bug number?

Original comment by classi...@floodgap.com on 15 Sep 2011 at 1:19

Contributor

GoogleCodeExporter commented Aug 9, 2015

Do you have a Mozilla bug number?

Original comment by classi...@floodgap.com on 15 Sep 2011 at 1:19

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
https://bugzilla.mozilla.org/show_bug.cgi?id=641597

Original comment by amc...@gmail.com on 18 Sep 2011 at 12:32

Contributor

GoogleCodeExporter commented Aug 9, 2015

https://bugzilla.mozilla.org/show_bug.cgi?id=641597

Original comment by amc...@gmail.com on 18 Sep 2011 at 12:32

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
This is the exact same issue as Mozilla's 641597. So this is Mozilla's problem. 
I'll report over there what I've found about how to trigger it etc.

Original comment by chtru...@web.de on 18 Sep 2011 at 1:17

Contributor

GoogleCodeExporter commented Aug 9, 2015

This is the exact same issue as Mozilla's 641597. So this is Mozilla's problem. 
I'll report over there what I've found about how to trigger it etc.

Original comment by chtru...@web.de on 18 Sep 2011 at 1:17

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
The bug is already in Firefox 4.0 beta 3 (but not beta 2). I think this issue 
can be closed as invalid.

Original comment by chtru...@web.de on 20 Sep 2011 at 2:45

Contributor

GoogleCodeExporter commented Aug 9, 2015

The bug is already in Firefox 4.0 beta 3 (but not beta 2). I think this issue 
can be closed as invalid.

Original comment by chtru...@web.de on 20 Sep 2011 at 2:45

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
I'll change this to upstream. It is entirely possible this is a PPC only bug, 
but no idea what would have broken it. Still, I think we should track it since 
it disproportionately affects us.

Original comment by classi...@floodgap.com on 21 Sep 2011 at 4:16

  • Changed title: Menu bar becomes unresponsive when hovering Toolbar menus [M641597]
  • Changed state: Upstream
  • Added labels: Mozilla
  • Removed labels: Milestone-NextBeta7
Contributor

GoogleCodeExporter commented Aug 9, 2015

I'll change this to upstream. It is entirely possible this is a PPC only bug, 
but no idea what would have broken it. Still, I think we should track it since 
it disproportionately affects us.

Original comment by classi...@floodgap.com on 21 Sep 2011 at 4:16

  • Changed title: Menu bar becomes unresponsive when hovering Toolbar menus [M641597]
  • Changed state: Upstream
  • Added labels: Mozilla
  • Removed labels: Milestone-NextBeta7
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Hm, bug 641597 indicates the bug also occurs on Intel, even under 10.6. Still 
it's weird that it affects only few people, otherwise Mozilla would have fixed 
this a long time ago given the size of their user base and the disturbing 
effect the bug has. 

Original comment by chtru...@web.de on 21 Sep 2011 at 5:52

Contributor

GoogleCodeExporter commented Aug 9, 2015

Hm, bug 641597 indicates the bug also occurs on Intel, even under 10.6. Still 
it's weird that it affects only few people, otherwise Mozilla would have fixed 
this a long time ago given the size of their user base and the disturbing 
effect the bug has. 

Original comment by chtru...@web.de on 21 Sep 2011 at 5:52

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
I'm unable to trigger this bug in TenFourFox 12 and 13. So I figure it must 
have been repaired (maybe by accident) somewhere between FF 11 and 12.

Original comment by chtru...@web.de on 31 May 2012 at 12:44

Contributor

GoogleCodeExporter commented Aug 9, 2015

I'm unable to trigger this bug in TenFourFox 12 and 13. So I figure it must 
have been repaired (maybe by accident) somewhere between FF 11 and 12.

Original comment by chtru...@web.de on 31 May 2012 at 12:44

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Would be nice to know what fixed it and maybe backport it to stable. Let's see 
if Steven has any ideas.

Original comment by classi...@floodgap.com on 31 May 2012 at 1:13

Contributor

GoogleCodeExporter commented Aug 9, 2015

Would be nice to know what fixed it and maybe backport it to stable. Let's see 
if Steven has any ideas.

Original comment by classi...@floodgap.com on 31 May 2012 at 1:13

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
(OTOH, we use significantly different chrome code now, so it's possible I fixed 
it by accident)

Original comment by classi...@floodgap.com on 31 May 2012 at 1:13

Contributor

GoogleCodeExporter commented Aug 9, 2015

(OTOH, we use significantly different chrome code now, so it's possible I fixed 
it by accident)

Original comment by classi...@floodgap.com on 31 May 2012 at 1:13

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Chris, are you still not able to trigger this in 17? Since 17 will shortly 
become stable, we can just call this "Fixed."

Original comment by classi...@floodgap.com on 11 Oct 2012 at 5:13

Contributor

GoogleCodeExporter commented Aug 9, 2015

Chris, are you still not able to trigger this in 17? Since 17 will shortly 
become stable, we can just call this "Fixed."

Original comment by classi...@floodgap.com on 11 Oct 2012 at 5:13

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
I haven't been able to trigger this for a long time, and it hasn't occurred by 
accident. Just tried it again in 17, it seems to be fixed.

Original comment by chtru...@web.de on 12 Oct 2012 at 5:28

Contributor

GoogleCodeExporter commented Aug 9, 2015

I haven't been able to trigger this for a long time, and it hasn't occurred by 
accident. Just tried it again in 17, it seems to be fixed.

Original comment by chtru...@web.de on 12 Oct 2012 at 5:28

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
I love the ones that fix themselves!

Original comment by classi...@floodgap.com on 12 Oct 2012 at 5:35

  • Changed state: Started
Contributor

GoogleCodeExporter commented Aug 9, 2015

I love the ones that fix themselves!

Original comment by classi...@floodgap.com on 12 Oct 2012 at 5:35

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Aug 9, 2015

Contributor
Marking WFM.

Original comment by classi...@floodgap.com on 20 Nov 2012 at 6:12

  • Changed state: WorksForMe
Contributor

GoogleCodeExporter commented Aug 9, 2015

Marking WFM.

Original comment by classi...@floodgap.com on 20 Nov 2012 at 6:12

  • Changed state: WorksForMe

@classilla classilla reopened this Jun 30, 2017

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Jun 30, 2017

Owner

Reopened as "regressed" in FPR1 (most likely it had just been wallpapered).

Current speculative fix idea is to just close the drop down popup when moving the mouse off. @chris-chtrusch , what do you think of that? Would that be annoying?

Owner

classilla commented Jun 30, 2017

Reopened as "regressed" in FPR1 (most likely it had just been wallpapered).

Current speculative fix idea is to just close the drop down popup when moving the mouse off. @chris-chtrusch , what do you think of that? Would that be annoying?

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Jun 30, 2017

Collaborator

I'm not sure. We might get more complaints about unexpected UI behavior than we would have about the actual bug. Maybe first give it a shot in the next beta and see if it fixes the bug at all?

Is there a way to get hold of a debug build to see what's happening in the browser when the bug is triggered? Anything to look for in the console or browser toolbox (the one that can debug the browser's own JS with remote access)?

Collaborator

chris-chtrusch commented Jun 30, 2017

I'm not sure. We might get more complaints about unexpected UI behavior than we would have about the actual bug. Maybe first give it a shot in the next beta and see if it fixes the bug at all?

Is there a way to get hold of a debug build to see what's happening in the browser when the bug is triggered? Anything to look for in the console or browser toolbox (the one that can debug the browser's own JS with remote access)?

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Jul 29, 2017

Collaborator

Log from debug build with comments.
issue72 console.pdf

Collaborator

chris-chtrusch commented Jul 29, 2017

Log from debug build with comments.
issue72 console.pdf

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Jul 29, 2017

Owner

It looks like that whole code segment is being triggered as a fall through with the popup open, so I'll probably need to put more debugging lines in there to figure it out. However, it does not seem to be caught by the solution for issue #248 and it should be unless it's not a mousedown that is being misdelivered.

Owner

classilla commented Jul 29, 2017

It looks like that whole code segment is being triggered as a fall through with the popup open, so I'll probably need to put more debugging lines in there to figure it out. However, it does not seem to be caught by the solution for issue #248 and it should be unless it's not a mousedown that is being misdelivered.

classilla added a commit that referenced this issue Aug 2, 2017

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Aug 6, 2017

Collaborator

Log from debug build for FPR2 (release version) with comments.
issue72 console with TenFourFoxDebug-FPR2.pdf

Collaborator

chris-chtrusch commented Aug 6, 2017

Log from debug build for FPR2 (release version) with comments.
issue72 console with TenFourFoxDebug-FPR2.pdf

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Aug 7, 2017

Owner

Event type 5 is NSMouseMoved. I guess that makes sense.

Owner

classilla commented Aug 7, 2017

Event type 5 is NSMouseMoved. I guess that makes sense.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Aug 7, 2017

Owner

One idea I have is to move the check for menubar clicks being misdelivered to the top of the event routine. Then it doesn't matter if the target is shot or not. Do other clicks in the window still work when this happens?

Owner

classilla commented Aug 7, 2017

One idea I have is to move the check for menubar clicks being misdelivered to the top of the event routine. Then it doesn't matter if the target is shot or not. Do other clicks in the window still work when this happens?

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Aug 7, 2017

Collaborator

Yes, inside the application window everything works as it should when the bug has been triggered.

Collaborator

chris-chtrusch commented Aug 7, 2017

Yes, inside the application window everything works as it should when the bug has been triggered.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 4, 2017

Owner

Based on that I think I have a speculative fix (and I added some more debugging info in case that fails as well). I'm checking it doesn't regress anything and if not it will be in the next beta.

Owner

classilla commented Sep 4, 2017

Based on that I think I have a speculative fix (and I added some more debugging info in case that fails as well). I'm checking it doesn't regress anything and if not it will be in the next beta.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 9, 2017

Owner

Chris, are you still able to trigger the bug, or is it fixed now?

Owner

classilla commented Sep 9, 2017

Chris, are you still able to trigger the bug, or is it fixed now?

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 9, 2017

Collaborator

I can still trigger it it FPR3b1. Going to try with the debug build this weekend.

Collaborator

chris-chtrusch commented Sep 9, 2017

I can still trigger it it FPR3b1. Going to try with the debug build this weekend.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 9, 2017

Collaborator

Log from debug build for FPR3b1 with comments. This time a complete cycle from startup to quit.
issue72.console.with.TenFourFoxDebug-FPR3b1.pdf

Collaborator

chris-chtrusch commented Sep 9, 2017

Log from debug build for FPR3b1 with comments. This time a complete cycle from startup to quit.
issue72.console.with.TenFourFoxDebug-FPR3b1.pdf

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 9, 2017

Owner

That's obnoxious. It looks like the problem is in a different area of code entirely.

Owner

classilla commented Sep 9, 2017

That's obnoxious. It looks like the problem is in a different area of code entirely.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 9, 2017

Owner

So this is very strange. When the bug triggers, let me clarify something from your trace: does trying to deliver this event too (1) appear when you click on the menu bar? If you have the Console window open, does that immediately appear every time you click? Is it always followed by don't know this event type (1)! sending to super?

Event type 1 is NSLeftMouseDown and that should have been intercepted by the fix for issue #248.

Owner

classilla commented Sep 9, 2017

So this is very strange. When the bug triggers, let me clarify something from your trace: does trying to deliver this event too (1) appear when you click on the menu bar? If you have the Console window open, does that immediately appear every time you click? Is it always followed by don't know this event type (1)! sending to super?

Event type 1 is NSLeftMouseDown and that should have been intercepted by the fix for issue #248.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 9, 2017

Collaborator

If the bug is triggered, one click on the menu bar immediately produces exactly one instance of "trying to deliver this event too (1)" followed by "don't know this event type (1)! sending to super".

If I click on the menu bar every ten seconds and do nothing else, the log looks like this (attachment).
issue72.console.with.TenFourFoxDebug-FPR3b1(2).pdf

Collaborator

chris-chtrusch commented Sep 9, 2017

If the bug is triggered, one click on the menu bar immediately produces exactly one instance of "trying to deliver this event too (1)" followed by "don't know this event type (1)! sending to super".

If I click on the menu bar every ten seconds and do nothing else, the log looks like this (attachment).
issue72.console.with.TenFourFoxDebug-FPR3b1(2).pdf

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 10, 2017

Collaborator

BTW, the situation can still be remedied by right-clicking the tab bar and choosing Customize from the context menu, then exiting Customize. Likewise by simply closing the browser window. The old method (toggle tabs on top) istn't an option anymore, of course. Here's what happens when I click Customize.
issue72.console.with.TenFourFoxDebug-FPR3b1(3).pdf

Collaborator

chris-chtrusch commented Sep 10, 2017

BTW, the situation can still be remedied by right-clicking the tab bar and choosing Customize from the context menu, then exiting Customize. Likewise by simply closing the browser window. The old method (toggle tabs on top) istn't an option anymore, of course. Here's what happens when I click Customize.
issue72.console.with.TenFourFoxDebug-FPR3b1(3).pdf

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 25, 2017

Owner

I've rewritten the debug code that emits the don't know this event type message to give a Y location for the click, since the handler for #248 (which should handle this for the top menu) is failing.

Owner

classilla commented Sep 25, 2017

I've rewritten the debug code that emits the don't know this event type message to give a Y location for the click, since the handler for #248 (which should handle this for the top menu) is failing.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 25, 2017

Collaborator

Looks like this in FPR3 final:

2017/09/25 11:03:00 [0x0-0xf37f37].com.floodgap.tenfourfoxdebug trying to deliver this event too (1)
2017/09/25 11:03:00 [0x0-0xf37f37].com.floodgap.tenfourfoxdebug don't know this event type (1) (y=136.000000)! sending to super

Do you need the full log?

Collaborator

chris-chtrusch commented Sep 25, 2017

Looks like this in FPR3 final:

2017/09/25 11:03:00 [0x0-0xf37f37].com.floodgap.tenfourfoxdebug trying to deliver this event too (1)
2017/09/25 11:03:00 [0x0-0xf37f37].com.floodgap.tenfourfoxdebug don't know this event type (1) (y=136.000000)! sending to super

Do you need the full log?

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 25, 2017

Owner

No, but what I do need to know is if the Y-location is always 136 (or within a 22-pixel range including that value, which would be the menu bar). Does it change based on where you click? Does it change relative to screen resolution or the position of the window?

Owner

classilla commented Sep 25, 2017

No, but what I do need to know is if the Y-location is always 136 (or within a 22-pixel range including that value, which would be the menu bar). Does it change based on where you click? Does it change relative to screen resolution or the position of the window?

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 25, 2017

Collaborator

The y location depends on where I click in the menu bar. Clicking a bit lower in the menu bar gives a slightly higher value (and vive versa), obviously corresponding to pixels.

The y location value also depends on the position of the browser window at the time the bug is triggered:
•Window at default position (fresh profile): values between 127 and 145
•Window a bit lower on screen: values between 163 and 181
•Window a lot lower: values between 350 and 368
(Changing the window position after the bug was triggered makes no difference in the y position.)

Screen resolution: If the bug triggers and I then switch to a lower screen resolution, the menu bar becomes responsive again (!) Not so, however, if I switch to a higher resolution, e.g. triggering it at 1024x768 and then switching to 1440x900. In this case, the bug persists and the y value increases by about 130 pixels, which is possibly the difference between 900 and 768.

Collaborator

chris-chtrusch commented Sep 25, 2017

The y location depends on where I click in the menu bar. Clicking a bit lower in the menu bar gives a slightly higher value (and vive versa), obviously corresponding to pixels.

The y location value also depends on the position of the browser window at the time the bug is triggered:
•Window at default position (fresh profile): values between 127 and 145
•Window a bit lower on screen: values between 163 and 181
•Window a lot lower: values between 350 and 368
(Changing the window position after the bug was triggered makes no difference in the y position.)

Screen resolution: If the bug triggers and I then switch to a lower screen resolution, the menu bar becomes responsive again (!) Not so, however, if I switch to a higher resolution, e.g. triggering it at 1024x768 and then switching to 1440x900. In this case, the bug persists and the y value increases by about 130 pixels, which is possibly the difference between 900 and 768.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 25, 2017

Owner

This is very clearly an OS bug that we've somehow managed to trigger, but those values are so all over the place I'm not sure how to work around it now. The Tiger problem was very easy to fix once it was obvious the clicks were somewhere a window couldn't possibly ever be. Here, however, the Y value being reported is actually truly within the content area. I may have to have some sort of CGEventTap to get the raw coordinates and that's going to be an ugly fix.

Owner

classilla commented Sep 25, 2017

This is very clearly an OS bug that we've somehow managed to trigger, but those values are so all over the place I'm not sure how to work around it now. The Tiger problem was very easy to fix once it was obvious the clicks were somewhere a window couldn't possibly ever be. Here, however, the Y value being reported is actually truly within the content area. I may have to have some sort of CGEventTap to get the raw coordinates and that's going to be an ugly fix.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Sep 26, 2017

Collaborator

In this case it might be preferable to try your solution from comment
#72 (comment)
so that we don't trigger the bug in the first place. I.e., either close the drop-down menu when moving the mouse off and don't open the next one automatically, or (better) leave the drop-down open until you click on the next item in the toolbar (like Safari).

Collaborator

chris-chtrusch commented Sep 26, 2017

In this case it might be preferable to try your solution from comment
#72 (comment)
so that we don't trigger the bug in the first place. I.e., either close the drop-down menu when moving the mouse off and don't open the next one automatically, or (better) leave the drop-down open until you click on the next item in the toolbar (like Safari).

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Sep 26, 2017

Owner

That's going to be my fallback, but my first pass will be to see if I can recover the original CG(S)Event and if it is similarly affected.

Owner

classilla commented Sep 26, 2017

That's going to be my fallback, but my first pass will be to see if I can recover the original CG(S)Event and if it is similarly affected.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Oct 21, 2017

Owner

Okay, I think I have something that works. I was able to trigger the bug on a debug build with my 10.5 DLSD PowerBook and have the code intercept and retarget the menu event.

There are actually two OS bugs occurring simultaneously. The first one appears to happen when the OS gets overwhelmed with top level events from Firefox/TenFourFox's popup windows. (There are many bugs like this with popup windows, such as bug 443178 which gave me a clue as to the second OS bug in this issue, or bug 425556, which is a different fix which they ended up not using.) When this occurs, the event seems to get "stuck" and interferes with other top level events; I kept seeing the event type 15 over and over in the log.

The second OS bug is why I couldn't fix it right the first time and also why the fix for #248 didn't help here. The CGEvent that underlies the NSEvent we receive is actually verifiably wrong: the Y coordinate is window-relative, not screen-relative, so we can never determine that the click is on the menu bar this way. This isn't a problem normally because there is a whole lot of exception code in TenFourFox/Firefox for getting correct mouse positions, but only for certain specific event types, not all of them (and the browser never expected this to occur, so this specific case isn't checked for).

However, the fix for bug 443178 has a different way of getting the mouse position directly from the NSEvent. This method is accurate on 10.5, so we use that.

There is a slight drop in performance when the bug triggers because the stuck event repeats over and over. It harmlessly gets bounced to the super, which ignores it, but it still has to be handled. At least this way the menu bar still works, but it may not be possible to prevent the root issue without a change in browser behaviour like the ones above.

I consolidated this fix with #248 because they both end up doing the same thing once the situation is detected, but because that bug is also very hard to trigger, I have kept the same code path (i.e., I reorganized it, but didn't change it). The [NSEvent mousePosition] method would be faster than what it does, and should work for both 10.4 and 10.5, so I might do this for FPR5 early so that I can test it a lot (it does happen on Tiger too, and I can trigger it with lots of keyboarding).

Anyway, you should be able to see Menu event dropped by OS! when this situation or #248 triggers in a debug build. Should be out early next week; I'm doing some last minute validation on something else before I run the entire build cycle for FPR4b1.

Owner

classilla commented Oct 21, 2017

Okay, I think I have something that works. I was able to trigger the bug on a debug build with my 10.5 DLSD PowerBook and have the code intercept and retarget the menu event.

There are actually two OS bugs occurring simultaneously. The first one appears to happen when the OS gets overwhelmed with top level events from Firefox/TenFourFox's popup windows. (There are many bugs like this with popup windows, such as bug 443178 which gave me a clue as to the second OS bug in this issue, or bug 425556, which is a different fix which they ended up not using.) When this occurs, the event seems to get "stuck" and interferes with other top level events; I kept seeing the event type 15 over and over in the log.

The second OS bug is why I couldn't fix it right the first time and also why the fix for #248 didn't help here. The CGEvent that underlies the NSEvent we receive is actually verifiably wrong: the Y coordinate is window-relative, not screen-relative, so we can never determine that the click is on the menu bar this way. This isn't a problem normally because there is a whole lot of exception code in TenFourFox/Firefox for getting correct mouse positions, but only for certain specific event types, not all of them (and the browser never expected this to occur, so this specific case isn't checked for).

However, the fix for bug 443178 has a different way of getting the mouse position directly from the NSEvent. This method is accurate on 10.5, so we use that.

There is a slight drop in performance when the bug triggers because the stuck event repeats over and over. It harmlessly gets bounced to the super, which ignores it, but it still has to be handled. At least this way the menu bar still works, but it may not be possible to prevent the root issue without a change in browser behaviour like the ones above.

I consolidated this fix with #248 because they both end up doing the same thing once the situation is detected, but because that bug is also very hard to trigger, I have kept the same code path (i.e., I reorganized it, but didn't change it). The [NSEvent mousePosition] method would be faster than what it does, and should work for both 10.4 and 10.5, so I might do this for FPR5 early so that I can test it a lot (it does happen on Tiger too, and I can trigger it with lots of keyboarding).

Anyway, you should be able to see Menu event dropped by OS! when this situation or #248 triggers in a debug build. Should be out early next week; I'm doing some last minute validation on something else before I run the entire build cycle for FPR4b1.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Oct 22, 2017

Collaborator

Sounds convincing. Because of the bureaucracy involved in two German ISPs quarrelling about the right to provide me with their services I haven't had a wired internet connection in my appartment for a month. It may take several weeks still before everything is settled. I'll try and download FPR4b1 anyway but it may take a bit longer than usual.

Collaborator

chris-chtrusch commented Oct 22, 2017

Sounds convincing. Because of the bureaucracy involved in two German ISPs quarrelling about the right to provide me with their services I haven't had a wired internet connection in my appartment for a month. It may take several weeks still before everything is settled. I'll try and download FPR4b1 anyway but it may take a bit longer than usual.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Oct 23, 2017

Collaborator

Menu bar stays responsive in FPR4b1, will verify with logs from debug build later.

Collaborator

chris-chtrusch commented Oct 23, 2017

Menu bar stays responsive in FPR4b1, will verify with logs from debug build later.

@chris-chtrusch

This comment has been minimized.

Show comment
Hide comment
@chris-chtrusch

chris-chtrusch Oct 26, 2017

Collaborator

Indeed I still see lots of "no target for this event (15)! sending to super" and the occasional "Menu event dropped by OS! (y=0.000000, type=1)" with the FPR4b1 debug build. So the bug is still present but the menu bar stays responsive as expected with this fix.

Collaborator

chris-chtrusch commented Oct 26, 2017

Indeed I still see lots of "no target for this event (15)! sending to super" and the occasional "Menu event dropped by OS! (y=0.000000, type=1)" with the FPR4b1 debug build. So the bug is still present but the menu bar stays responsive as expected with this fix.

@classilla

This comment has been minimized.

Show comment
Hide comment
@classilla

classilla Oct 27, 2017

Owner

Good, then that's at least good enough for now. I'll leave this open for the time being while I ensure #248 didn't get regressed. Assuming it didn't, I'll close this and open a tracking ticket to see if there's a better solution.

Owner

classilla commented Oct 27, 2017

Good, then that's at least good enough for now. I'll leave this open for the time being while I ensure #248 didn't get regressed. Assuming it didn't, I'll close this and open a tracking ticket to see if there's a better solution.

@classilla classilla closed this in 35ce197 Oct 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment