Closed
Bug 301567
Opened 19 years ago
Closed 19 years ago
Redraw bug in refreshing no-scrolling frame when closing another tab after scrollbar used
Categories
(Core Graveyard :: Widget: Mac, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: waynegwoods, Assigned: jaas)
References
()
Details
(Keywords: regression, testcase)
Attachments
(3 files, 1 obsolete file)
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.
Reporter | ||
Comment 1•19 years ago
|
||
Open this attachment, and then open a new tab and follow the instructions as described in comment 1.
Reporter | ||
Comment 2•19 years ago
|
||
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
Flags: blocking-aviary1.1?
Comment 3•19 years ago
|
||
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
Reporter | ||
Comment 4•19 years ago
|
||
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•19 years ago
|
||
Is refreshing a requirement? I can reproduce the bug with the attached testcase before the frame begins reloading.
Comment 6•19 years ago
|
||
I can reproduce, although possibly not as easily, with the 0622 build. Further scrollbar updates following bug 282940 may have exacerbated the problem.
Reporter | ||
Comment 7•19 years ago
|
||
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.
Reporter | ||
Comment 8•19 years ago
|
||
Comment 9•19 years ago
|
||
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.
Reporter | ||
Comment 10•19 years ago
|
||
This is the equivalent frame page, but no refreshing.
Reporter | ||
Comment 11•19 years ago
|
||
Sorry, ignore that last one. Wrong file.
Attachment #190077 -
Attachment is obsolete: true
Reporter | ||
Comment 12•19 years ago
|
||
Can't seem to reproduce with the non-refreshing case, above. Can anyone else?
Comment 13•19 years ago
|
||
No - now that we've established it's a destruction thing, it makes sense that it wouldn't be reproducible without refreshing.
Comment 14•19 years ago
|
||
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?
Reporter | ||
Comment 15•19 years ago
|
||
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. :)
Updated•19 years ago
|
Flags: blocking-aviary1.5? → blocking-aviary1.5-
Reporter | ||
Comment 16•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
Comment 17•19 years ago
|
||
Probably bug 301807.
You need to log in
before you can comment on or make changes to this bug.
Description
•