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



14 years ago
9 years ago


(Reporter: waynegwoods, Assigned: jaas)


({regression, testcase})

Mac OS X
regression, testcase
Bug Flags:
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)




(3 attachments, 1 obsolete attachment)



14 years ago
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

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, )
- 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

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

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

14 years ago
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.

Comment 2

14 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

14 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

Comment 4

14 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

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

Comment 6

14 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.

Comment 7

14 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.

Comment 8

14 years ago
Created attachment 190075 [details]
Non-refreshing equivalent of attachment 180257 [details] - to be used with the next attachment, not to be used directly

Comment 9

14 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.

Comment 10

14 years ago
Created attachment 190077 [details]
Page with non-refreshing frames

This is the equivalent frame page, but no refreshing.

Comment 11

14 years ago
Created attachment 190078 [details]
Page with non-refreshing frames

Sorry, ignore that last one. Wrong file.
Attachment #190077 - Attachment is obsolete: true

Comment 12

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

Comment 13

14 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

14 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:

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

Comment 15

14 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. :)


14 years ago
Flags: blocking-aviary1.5? → blocking-aviary1.5-

Comment 16

14 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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Comment 17

14 years ago
Probably bug 301807.


9 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.