306133 - Artifacts in popup block alert, when using scrollbar during page loading

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Widget: Mac, defect)

Description

[Wayne Woods]

Probably related to other native scrollbar bugs like bug 304607 and bug 298677.

With popup blocking enabled, go to a page with a blocked popup (such as
http://search.about.com/fullsearch.htm )

Wait until the page draws its scrollbar, but *before* the alert appears at the
top of the page that a popup has been blocked. Move the scrollbar up and down.

When the popup alert is added to the top of the page, it fails to actually draw.
It instead appears as whatever was drawn at the top of the page before the popup
alert pushed it further down. This includes a section of the scrollbar.

Playing with the scrollbar further seems to force it to draw properly.

This was reproduced in the latest Mac trunk nightly, and also the Fx 1.5 (Moz
1.8) branch. Fresh profile, no added extensions or themes.

Could the native scrollbar widget be backed out of the branch at this point? I
know this series of bugs contains nothing critical, but it just looks a bit bad
if we try to encourage Mac users to switch when 1.5 is released.

cheers

Comment 1

[Wayne Woods]

Stephen, you must be an American. "Artefact" is a perfectly legitimate spelling ;)

Comment 2

[Josh Aas]

Mark has dealt with this stuff before, probably knows more than me. -> mento

Comment 3

[Mark Mentovai]

Wayne, can you test with a current trunk build of Firefox?  I have a feeling that bug 306133 fixed this.

Comment 4

[Wayne Woods]

Hey Mark,

The original URL I quoted no longer seems to use pop-ups. I had trouble finding another site that did, and that also drew the scrollbar before the pop-up block warning was displayed.

One I found was: http://www.popuptest.com/popuptest3.html
It gives a new pop-up every 5 seconds, so is good for testing.

You can navigate to that page and reduce the browser window size so that a vertical scroll bar appears. Then click to remove the initial pop-up block warning. Quickly, start moving the scroll bar until the next pop-up is blocked a few seconds later.

Doing this, I find that the artefact still appears *until* I let go of the scrollbar. The pop-up block warning won't appear while the scrollbar is still held, causing temporary rendering issues. You can still tell that the pop-up was blocked by the fact that the scrollbar changes shape, and the artefact at the top of the page, where the warning message should be. These are immediately resolved once the scrollbar is released. Once you let go, everything looks fine.

So the problem is now extremely minor, as it corrects quickly, but it appears that clicking and holding the scrollbar blocks certain aspects of window drawing, which queue up until it's released. While it seems extremely minor, I wonder if the underlying cause might create larger problems at some future stage.

Oh, and there's one situation where it doesn't immediately correct. In fact letting go of the scrollbar makes it worse:
Before the pop-up block message is drawn, move the scrollbar a little. Then STOP moving it, but continue to click and hold on it. Then, as soon as the scrollbar changes shape (indicating a blocked pop-up), release it. The warning message will appear at the top, but notice that the scrollbar arrows at the bottom of the window have vanished. They are redrawn as soon as the scrollbar moves again.  Once again, this is obviously a very minor issue.

Oh, and I'm using the latest trunk nightly, in OS X 10.4.3.

Cheers,

Wayne

Comment 5

[Mark Mentovai]

While in scrollbar tracking, the main thread and therefore the UI is supposed to be blocked.  The problem is that the internal event loop for scrollbar tracking is based on CFRunLoop, and since PLEvents were moved to this type of event handling, scrollbar tracking is actually free to fire PLEvents.  Now, scrollbar tracking isn't really fully blocking, it puts us into a bogus semi-async state that causes all sorts of problems like this one.

What's probably going on here is that we're doing async updates from things on PLEvents, but because the scrollbar is in tracking and the rest of the app is blocked, the update is delayed until the app starts moving again.