299643 - Not painting reliably while widgets are held

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Widget: Mac, defect)

Description

[Mark Mentovai]

Since bug 282940 and bug 271050, switching from WaitNextEvent to CFRunLoopSource:

In the past, if the mouse was held down in the menu or scroll bar, the
application would stop making progress.  The new event handling has fixed that,
but now, repainting isn't happening when it should while the mouse is down on
these widgets.

Example: Attempt to visit www.mozilla.org.  As soon as you press return, mouse
down in the menu bar.  The new page doesn't paint until the mouse is released. 
If it would have painted on other platforms (can't check now, but I'm pretty
sure it would have), then it should paint on the Mac too, even while mousing
around in the menus.

Now, try a more complicated layout like www.nytimes.com or www.cnn.com.  Same
result.  Try visiting the site, but don't mouse down in the menu bar until you
see the page begin to draw.  Some parts of the page may draw while the mouse is
down, but the page won't draw in its entirety until the mouse is released.

Now, fire up a download and open the download manager.  Mouse down while
watching the progress bar.  It stops moving, and the per-download counters stop
too, but the title bar correctly updates as progress is made.

Comment 1

[Simon Fraser [no longer active]]

I wonder if we'd have to switch to carbon events to fix this?

Comment 2

[Mark Mentovai]

*** Bug 300282 has been marked as a duplicate of this bug. ***

Comment 3

[Asaf Romano (gone)]

*** Bug 300280 has been marked as a duplicate of this bug. ***