301567 - Redraw bug in refreshing no-scrolling frame when closing another tab after scrollbar used

Status: RESOLVED WORKSFORME

(Core Graveyard :: Widget: Mac, defect)

Description

[Wayne Woods]

This is a remnant of bug 289766. While the general case for that bug seems to
have stopped occuring, there are specific circumstances in which it still
occurs. Rather than reopen that one, I'll open this new one with the specific
case...

To reproduce:
- Go to a page that contains a frame that has scrolling="no", and refreshes
(see the attachment)
- Open a second tab and take it to a page that is long enough so that the
vertical scroll bar appears (say, http://slashdot.org )
- In the second tab, move the scroll bar up and down a few times
- Ensure the frame in the first tab refreshes at least once (you can tell this
without being in that tab by watching for when the tab title flickers), either
before or after you move the scroller in the second tab. Don't go back to that
tab, though, or the bug won't occur
- Close the second tab, thus revealing the first one again. Hopefully you'll
notice that the refreshing frame (top, blue frame in the attachment) has been
replaced by the contents from the second tab, and the tab bar is still present,
even if it should have closed. If it doesn't do it the first time, repeat the
above procedure.
- If you click on another frame in the same window, or simply switch between
tabs quickly, or even wait for the next refresh, then the frame should redraw
correctly.

This regression seems to have occurred between the 20050403 and 20050404 trunk
builds. It's Mac OS X-only, and occurs in both Firefox and Seamonkey.

It seems to be important that the frame containing the refresh contains
scrolling="no". The nature of any other frame in the same page seems to be
irrelevant.

In the original form of this bug (as reported in bug 289766), you:
(1) didn't have to move the scroller
(2) didn't have to close the second tab. Just switching between tabs was enough.
Something must have changed to minimize the regression, but not remove it entirely.

Comment 1

[Wayne Woods]

Attachment: Page with refreshing frame

Open this attachment, and then open a new tab and follow the instructions as
described in comment 1.

Comment 2

[Wayne Woods]

More info (Sorry, I should have tested more intermediate builds first):
- It appears that bug 289766 *didn't* directly become this bug (although they
are probably still linked).
- Bug 289766 appears to have been fixed entirely in the 20050622 build.
Presumably by the CFRunLoopSource-based plevent handling added in bug 282940.
- *This* regression didn't appear until the 20050703 build

Given the scroller requirement for reproducing, I suspect the fix for bug
299384. It's the only patch in Bonsai during that time period that leapt out at me.

Comment 3

[Simon Fraser [no longer active]]

Related to bug 301478?

Comment 4

[Wayne Woods]

Possibly, although I note that bug 301478 has occurred for a lot longer, and the
drawing position for the bad scrollbar in that bug changed between the 20050706
and 20050707 builds (from far left to directly above scrollbar). So the dates
don't really match up.

Comment 5

[Mark Mentovai]

Is refreshing a requirement?  I can reproduce the bug with the attached testcase
before the frame begins reloading.

Comment 6

[Mark Mentovai]

I can reproduce, although possibly not as easily, with the 0622 build.  Further
scrollbar updates following bug 282940 may have exacerbated the problem.

Comment 7

[Wayne Woods]

What do you have to do to reproduce it with the 0622 build? I've tried more
times and still can't do so. All I see is that scrollbar redraw bug.

Comment 8

[Wayne Woods]

Attachment: Non-refreshing equivalent of attachment 180257 - to be used with the next attachment, not to be used directly

Comment 9

[Mark Mentovai]

I switched to the tab with frames immediately prior to or immediately following
(not sure) its starting to reload.  In bug 299384, I made the widget code
respond to teardown and stop drawing sooner, so the window to reproduce opened
up a bit.

Comment 10

[Wayne Woods]

Attachment: Page with non-refreshing frames

This is the equivalent frame page, but no refreshing.

Comment 11

[Wayne Woods]

Attachment: Page with non-refreshing frames

Sorry, ignore that last one. Wrong file.

Comment 12

[Wayne Woods]

Can't seem to reproduce with the non-refreshing case, above. Can anyone else?

Comment 13

[Mark Mentovai]

No - now that we've established it's a destruction thing, it makes sense that it
wouldn't be reproducible without refreshing.

Comment 14

[Mark Mentovai]

In an attempt to reproduce in an "official" build, I grabbed the freshest one I
had on hand, which was from 0719.  Guess what?  Couldn't reproduce.

It seems to me like this was fixed in 0708 by the first attempt in bug 298677. 
It remained fixed, and then broke in 0721.  So, the usual suspects:

http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2Fwidget%2Fsrc%2Fmac+mozilla%2Fgfx%2Fsrc%2Fmac&sortby=Date&date=explicit&mindate=2005-07-20+04%3A00&maxdate=2005-07-21+10%3A00

Wayne, would you mind testing with a few builds around these dates and verifying
what I found?

Comment 15

[Wayne Woods]

Hi Mark,

Sorry, but I CAN reproduce in every Firefox build from 0706 to 0721 (I tested
them all). Sometimes I had to repeat the procedure 3 or 4 times to get it to
work, though, but they definitely all have the regression. I don't have the 0704
and 0705 builds, but 0703 definitely has it too.

Try as hard as I might, I can't reproduce it in any build from 0702 or earlier.
And I've patiently tried for ages, and tried closing the tab just before or
after or during a frame reload. So I still don't know how you're managing to
reproduce it in those builds. There must be some subtlety to it. :)

Comment 16

[Wayne Woods]

I can't reproduce this bug anymore. It seems to have been fixed by something
between the 20050728 and 20050729 builds. Wonder what it was. ->WORKSFORME

Comment 17

[Mark Mentovai]

Probably bug 301807.