289766 - Redraw bug in refreshing no-scrolling frame when switching between tabs

Status: RESOLVED DUPLICATE of bug 296897

(Firefox :: General, defect)

Description

[Wayne Woods]

To reproduce:
- Go to a page that contains a frame that has scrolling="no", and refreshes
(I'll provide something as an attachment).
- Switch to a new tab (you can load something else in the new tab or leave it
blank, it doesn't matter).
- Wait until the frame refreshes in the first tab (you can tell this without
being in that tab by watching for when the tab title flickers).
- Switch back to that tab. Some of the time you'll notice that the refreshing
frame has been replaced by the contents from the second tab. 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 will draw correctly.

This regression seems to have occurred between the 20050403 and 20050404 trunk
builds. I think it's Mac OS X-only. I haven't seen it on Windows builds.

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.

Comment 1

[Wayne Woods]

Attachment: Test case. It's also necessary to download the second attachment.

Download both attachments... framebug.html and refresh.html and place them in
the same folder on your HDD.

Open framebug.html in your browser (don't open refresh.html.. it's used by
framebug.html in its first frame... if there's a way of embedding all this in
the one page, I don't know it, sorry).

Follow the instructions in the bug description. I've set the refresh rate to 5
seconds. When switching back from another tab, the top frame of framebug.html
will often show contents from the other tab, if the frame has been left long
enough to refresh.

Comment 2

[Wayne Woods]

Attachment: Second attachment (contains refreshing frame)

Comment 3

[Wayne Woods]

It also occurs in Seamonkey builds. When that's the case, do we still mark them
as Mozilla bugs? I wasn't sure if the focus had changed and we should leave them
as Firefox now.

cheers

Comment 4

[Martijn Wargers (dead)]

Attachment: Testcase that can be viewed online

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Does this affect anything but Firefox on Mac? In particular, does it affect Camino?

Comment 6

[Wayne Woods]

Thanks Martijn, for the online test case. I should have thought of that :)

This bug doesn't seem to affect Camino. I tested the most recent trunk nightly,
which was build 20050408.

As I mentioned before, it does affect Seamonkey, and began between builds
20050403-09 and 20050404-09 (the hour number for the build id was '11' in the
file name on the archive, but '09' inside the app.)

In Firefox, it began between 20050403-08 and 20050404-08.

Comment 7

[Wayne Woods]

I couldn't reproduce in Firefox 1.0.3 nightlies from that time period, so it
looks like it's trunk-only.

Looking at Bonsai, the only two bug fixes that stood out to my untrained eye
were those for bug 288117 and bug 288888.

Comment 8

[Wayne Woods]

Requesting blocker. This would be terrible if it made it into a release version.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Almost certainly a duplicate of 296897.

*** This bug has been marked as a duplicate of 296897 ***

Comment 10

[Wayne Woods]

I don't understand why this bug would be resolved to a later one with almost no
details, no diagnosis and no test case. But oh well, as long as it gets fixed :)

Comment 11

[Wayne Woods]

Just a warning - this bug can still be reproduced in special circumstances
(involving use of the scroller widget in the second tab). I suspect this
happened after the recent native scroller changes. I'll open a new bug about it
as soon as I can document a thorough reproducible test case.

Comment 12

[Wayne Woods]

New bug opened as bug 301567.