Closed Bug 33549 Opened 25 years ago Closed 25 years ago

frame reload knocks out preferences frame

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: pavlov)

References

()

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2+])

When the top (advertising) frame on any given cinescape.com page reloads and the preferences window is open, the right frame tries to reload too, but never comes back. Also, if a prefs child window is open it does the same thing as the right frame in the main prefs window. To reproduce: --go to www.cinescape.com --open preferences dialogue --wait until the banner ad in the top frame refreshes Expected: banner ad reloads, preferences window unchanged Actual: banner ad reloads, right side of preferences window disappears and becomes black (M14-crypto) or white (recent nightly). Selecting a topic from the left side refreshes the right side to a normal state, and it won't disappear again on further reloads of the banner ad. Also: --go to www.cinescape.com --open preferences dialogue --go to cookies/images topic --open "View stored Cookies" dialogue --wait until said banner ad refreshes Expected: banner ad reloads, pref window and child window unaltered Actual: entire child window wiped white, rendered unusable and must be shut by window manager. Tested on M14-crypto and most recent nightly (2000032711). i386 Linux glibc2.1 other builds/platforms untested
Further poking around shows that this happens on the "Manage Bookmarks" dialogue also (and so probably any other similar window.) The component part of bug should probably be changed accordingly, but I don't really know how to classify it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed on today's Linux CVS build (pulled just before the tree opened); all three cases are buggy. Left as 'Preferences', since the right component isn't any clearer to me than the original submitter.
Reassigning as per Don
Assignee: matt → ben
Severity: minor → normal
Keywords: nsbeta2
Target Milestone: --- → M17
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Pretty whacky. Using 2000051108 linux, it still happens: when an HTML IFRAME reloads in the browser, the right hand IFRAME in the prefs dialog is blanked out (and as noted above, there are a couple of other scenarios to reproduce this). CC: pollmann for frames, danm for windowing. [Note: mac and win32 are unaffected by this bug].
Keywords: pp
how come I get this? :P back to don...
Assignee: ben → don
Move to M18 target milestone.
Target Milestone: M17 → M18
Peter, can you help us out with this one? None of us have a clue as to why this happens. It's certainly not an "apps" thing -- probably more likely a windowing or frame targeting problem. Who should get that? Dan Matejka?
Assignee: don → trudelle
Component: Preferences → XP Toolkit/Widgets
Target Milestone: M18 → ---
wierd, doesn't happen immediately or every time - timer-related? assigning to pavlov
Assignee: trudelle → pavlov
Target Milestone: --- → M18
Unable to reproduce on today's linux build. Tried both methods reported to reproduce the bug, and let the ad image reload several times. The prefs window and cookies window remained ok. Can anyone confirm if this is fixed?
waiting on a build.... is/was this linux only?
Yes, this was linux only. I ran that page for quite a while today with prefs dialog open and that frame updating -- this doesn't seem to happen anymore. I think this is WORKSFORME (although it was pretty weird the way this used to happen).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Not so fast... using 2000061720 the Preferences window seems to be okay, but the problem persists for Image Manager, Bookmark Manager, Cookie Manager, and those sorts of windows. It also affects History, the JavaScript Console, and (hey, where'd XMLTerm go?) some others.
So, on Friday I didn't see this at all (in cookie manager as well as prefs). But with 2000061720 mozilla build, I can't seem to miss it (including blanking out prefs panel, or any of the tab panels in the cookie manager dialog). Reopening. Thanks James.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
over to jrgm to vfry... looks good to me from the preferences point-o'view.
QA Contact: sairuh → jrgm
verified fixed (or at least I couldn't reproduce it with 2000062120 linux in a half hour of various attempts -- James Cooper : please smack me in the head again if this comes back. Thanks).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.