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.
Created attachment 190015 [details] Page with refreshing frame Open this attachment, and then open a new tab and follow the instructions as described in comment 1.
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.
Component: GFX: Mac → Widget: Mac
Related to bug 301478?
Summary: Redraw bug in refreshing no-scrolling frame when closing another tab after scroller used → Redraw bug in refreshing no-scrolling frame when closing another tab after scrollbar used
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.
Is refreshing a requirement? I can reproduce the bug with the attached testcase before the frame begins reloading.
I can reproduce, although possibly not as easily, with the 0622 build. Further scrollbar updates following bug 282940 may have exacerbated the problem.
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.
Created attachment 190075 [details] Non-refreshing equivalent of attachment 180257 [details] - to be used with the next attachment, not to be used directly
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.
Created attachment 190077 [details] Page with non-refreshing frames This is the equivalent frame page, but no refreshing.
Created attachment 190078 [details] Page with non-refreshing frames Sorry, ignore that last one. Wrong file.
Attachment #190077 - Attachment is obsolete: true
Can't seem to reproduce with the non-refreshing case, above. Can anyone else?
No - now that we've established it's a destruction thing, it makes sense that it wouldn't be reproducible without refreshing.
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?
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. :)
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
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Probably bug 301807.
You need to log in before you can comment on or make changes to this bug.