Open
Bug 962942
Opened 11 years ago
Updated 2 years ago
Possibly delayed event processing of minimize/maximize/resize
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
NEW
People
(Reporter: avih, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [Australis:P-])
Apologies in advance for the not so good bug report. I've experience this bug for about 2 weeks now, but it usually doesn't happen more than once a day, and I don't know how to reproduce it. I'll continue trying to provide a good STR, but I'm not counting on succeeding.
Here are the symptoms:
- Sometimes when clicking one of the window's minimize/maximize/restore (not sure if always the same or if it also happens with other widgets), the click seems to "half register". I.e. the button looks pressed (even after I finished the mouse click and lift my finger), but the action doesn't happen, i.e. the window stays the same, and the button looks like I didn't lift my finger from the mouse.
- I then click the same widget again, and now it does work. I don't recall if I tried clicking another widget once it happens. I'll try to next time.
- Then I "go on" and try to do something within the page (again, not sure exactly what triggers it), and suddenly the "lost event" from earlier triggers (e.g. the window maximizes if the earlier maximize click was "half registered").
Initially I got a hunch that the window "transformation" (e.g. maximizing) animation got very slow/janky recently, and that maybe it's somehow related. But later I think the resize animation got better, but the bug still happens.
I only noticed the bug on OS X 10.9.1 (which is the only OS X system I have). I didn't notice it on Windows 7.
Reporter | ||
Comment 1•11 years ago
|
||
It just happened again. Here's the exact sequence:
- The window is not maximized and not minimized.
- I click the green '+' (maximize/restore) button, and lift my finger.
- The button looks pressed but the window doesn't maximize.
- I move the mouse over the other window buttons (close, minimize) and they get hover highlight working well. The maximize button still looks pressed all the time.
- I click the "Nightly" menu at the menu bar.
- The menu opens and the window maximizes.
I tried to reproduce it, but the next 30 or so maximize/restore all worked well. Tried clicking various areas of the page in between, still maximize/restore work well.
Might be worth noting that I have the pref browser.tabs.drawInTitlebar=false, so this is the native window titlebar - not the mixed one which is the default with Australis.
Comment 2•11 years ago
|
||
See also bug 962082. I've experienced both recently but haven't been able to reproduce the condition.
Comment 3•11 years ago
|
||
Tentatively blaming bug 953435.
Both clicking titlebar buttons and resizing the window causes a nested event loop to spawn from inside the processing of the mousedown event. When clicking the minimize button, the stack looks like this:
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
-[NSCell trackMouse:inRect:ofView:untilMouseUp:]
-[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:]
-[NSControl mouseDown:]
-[_NSThemeWidget mouseDown:]
-[NSWindow sendEvent:]
-[BaseWindow sendEvent:]
-[ToolbarWindow sendEvent:]
-[NSApplication sendEvent:]
-[GeckoNSApplication sendEvent:]
-[NSApplication run]
nsAppShell::Run()
nsAppStartup::Run()
XREMain::XRE_mainRun()
XREMain::XRE_main(int, char**, nsXREAppData const*)
Startup::XRE_Main
XRE_main
main
start
Blocks: 953435
Updated•11 years ago
|
Keywords: regression
Comment 4•11 years ago
|
||
Yeah, I mentioned to avih that bug 953435 is probably the bug to blame.
Reporter | ||
Comment 5•11 years ago
|
||
Here's another sequence of the bug with nightly 2014-01-23:
Clicked maximize and lifted the finger, window didn't maximize and the maximize button looks pressed (darker bg green with '+' visible):
- Tabs hover highlight ok
- I can two-fingers-scroll the page
- Mouse cursor reacts to hovering links at the content
- I can switch applications back and forth using command-tab
All the above while the window still didn't maximize and the maximize button still looks "pressed down".
- I clicked a link at the content and the window maximized (and "unlocked" the maximize button).
Reporter | ||
Comment 6•11 years ago
|
||
Also, on comment 5, before maximize finally kicked in, I was also able to click at a text box (yahoo search field), and it brought the cursor there correctly, and the window still didn't maximize.
Comment 7•11 years ago
|
||
I've seen this too ... oddly enough while testing the STR for bug 959281.
I can't reproduce it either. But I think there's a good chance that both bugs are caused by event starvation (or perhaps messing up the order in which events are processed). So fixing bug 959281 (for which we have good STR) should also fix this bug.
Updated•11 years ago
|
status-firefox29:
--- → affected
tracking-firefox29:
--- → ?
Comment 9•11 years ago
|
||
Since bug 962082 has been duped to this one, I'll post this here:
Evidently this problem also causes a different kind of misbehavior (bug 962082) when resizing the window.
Here's a pretty certain way to reproduce it:
- Grab a window edge and make the window larger
- While still moving the mouse, release the mouse button
- You should see the cursor not returning to normal state, but staying in resize state
- Click anywhere on the window (page or UI)
- The window will jump to that size
This becomes even more annoying by the fact that trying to resolve the issue (resizing the window) you are likely to trigger the problem again.
Comment 10•11 years ago
|
||
Yes, I can reproduce your STR. Thanks!
I agree it's probably related, and ultimately triggered by the patch for bug 953435. I'm working on it.
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Comment 11•11 years ago
|
||
I've posted an experimental patch at bug bug 959281. See bug 959281 comment #50.
Please try it out!
Updated•11 years ago
|
Updated•11 years ago
|
Summary: Possibly delayed event processing of minimize/maximize → Possibly delayed event processing of minimize/maximize/resize
Comment 12•11 years ago
|
||
(In reply to Steven Michaud from comment #11)
> I've posted an experimental patch at bug bug 959281. See bug 959281 comment
> #50.
>
> Please try it out!
Your patch seems to have solved the issue. I can't reproduce it with the patch applied :)
Comment 13•11 years ago
|
||
I'm putting this on the Australis whiteboard, because it only happens with Australis and should be fixed before it lands. Stevens patch works, at least with my setup, so hopefully that will speed things up here.
Whiteboard: [Australis:P2]
Comment 14•11 years ago
|
||
(In reply to Steven Michaud from comment #10)
> Yes, I can reproduce your STR. Thanks!
>
> I agree it's probably related, and ultimately triggered by the patch for bug
> 953435. I'm working on it.
Now that this has been backed out, is this bug WFM? Philipp and/or Steven?
Flags: needinfo?(smichaud)
Flags: needinfo?(philipp)
Comment 15•11 years ago
|
||
The resize part of the defect doesn't occur in Nightly 2014-02-04 anymore, so it does work for me :)
I don't know about maximize/minimize-issue though.
Flags: needinfo?(philipp)
Comment 16•11 years ago
|
||
As for the maximize/minimize issue, I just tried zooming a few times in today's m-c nightly and didn't see it. It almost certainly *is* fixed by the backout of bug 953435, but I've never been able to reproduce it, and so can't be certain.
Flags: needinfo?(smichaud)
Comment 17•11 years ago
|
||
Yeah, but we may need to fix this somehow, since bug 953435 is rather horrible bug and we need
that fixed.
Comment 18•11 years ago
|
||
You're right, Smaug. And no, I haven't forgotten.
Bug 959281 and this one are now my top priority until I can come up with some kind of real fix.
Comment 19•11 years ago
|
||
OK, but then I'm P-'ing for Australis as it seems we don't need to worry about this for 29, at least for now - if the other bug relands and/or this problem reoccurs on branches, maybe we need to reconsider, but this will get it off the front end team's prio list. :-)
Whiteboard: [Australis:P2] → [Australis:P-]
Reporter | ||
Comment 20•11 years ago
|
||
I haven't noticed the maximize/minimize/restore bug for the past couple of days.
Considering that my usage pattern hasn't changed and that I was noticing it at least once a day, I think it's very likely that the bug as it existed at the report in comment 0 is no more. For now.
I'll update if I do notice it even once from now on.
Comment 22•7 years ago
|
||
So, I've just noticed this happening to be today and yesterday.
Not sure if it's useful, but I managed to record a video of it. Pay attention to the cursor.
https://www.dropbox.com/s/nugy3xlvlj77oy6/firefox_bug.mov?dl=0
MacOS: 10.12.6
Macbook Pro 13" Early 2015 version.
Dual monitor setup.
Firefox: 55.0.2
Extensions active:
Cisco Webex Extension
Reddit Enhancement Suite
Video DownloadHelper
Comment 23•6 years ago
|
||
Has anyone using a Mac seen this recently?
Component: Event Handling → Widget: Cocoa
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•