Tracking native menus and scrollbars stops the app dead in its tracks

RESOLVED DUPLICATE of bug 338225

Status

RESOLVED DUPLICATE of bug 338225
12 years ago
9 years ago

People

(Reporter: mark, Assigned: mark)

Tracking

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
The new thread manager was supposed to take care of problems like this, but it didn't do the trick the whole way on the Mac because of Apple internal brain-death.  When we call MenuSelect (to track native menu use) or TrackControl (to track native control use, only scrollbars in our case), or when we use the Cocoa equivalents, the system enters its own tracking loop during which we do not process any Gecko events.
(Assignee)

Comment 1

12 years ago
Created attachment 230907 [details] [diff] [review]
Patch <v1

We may be able to do something here with run loop modes.  I also found that event loop timers fire while in MenuSelect, and wrote this implementation to provide good UI response while still allowing Gecko events to be processed.

(Note: the crusty menu rebuild code is only sorta-dynamic, so any approach taken here would need to make sure that bad things can't happen if the menus change while in tracking.)
(Assignee)

Comment 2

12 years ago
Run loop mode is OK.  I forgot that we turned off the clever solution from bug 337824 that was supposed to handle this case.  Never mind...

*** This bug has been marked as a duplicate of 338225 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Updated

9 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.