From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001009 BuildID: 2000100906 If you use an IFRAME and attempt to hide it by display: none and then retrieve it with display: block, the IFRAME will reload from its source. This causes data loss for any information stored in the IFRAME before it was reloaded. The reload happens as soon as the display is altered from none to block. Reproducible: Always Steps to Reproduce: Open the 2nd attachment I'll submit (the first will be the target for the IFRAME). Toggle the IFRAME using the button. Note that the time displayed (fired when the src document is read) is updated every time the IFAME is toggled. Actual Results: The IFRAME is reloaded from the server :( Expected Results: The browser should never reload a document unless the user presses reload or the programmer asks it to. I would expect that the IFRAME would maintain its original document no matter what I do to the style. This bug may be similar to bug 52334. OK, this is it. I'll grovel for this bug to be fixed. I'll buy beer/dew/jolt. Whatever it takes *PLEASE* get this into Netscape 6. IFRAMES are really useful for tab controls and hundreds of other nifty HTML tricks. This bug makes me go back to the bad old days of writing things twice. Once for IE (which performs as I would expect but doesn't work with my Mozilla work around) and once for Mozilla (with a ugly width:0 height: 0 hack) I consider this bug critical since it can result in data loss.
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen
Summary: using CSS display: xxx on IFRAMES causes data loss → using CSS display: xxx on IFRAMES causes data loss
Nominating for RTM since as per description, this can cause dataloss.
Keywords: correctness, dataloss, html4, rtm
So is the basic problem here that we're attaching data to frames that should be attached to the DOM?
It was a code-level question. I think we shouldn't be storing too much in the frame model, since it can get recreated on restyle.
David, the data from the any (nsI)frame that implements nsIStatefulFrame (e.g. a nsGfxTextControlFrame2) should be stored away in the pres-shell when it's display is set to none, and restored when the display is reset. In this case though, when the (nsI)frame for the <frame> is destroyed, it probably takes the entire webshell, preshell, document, and everything down with it - meaning that all nsIStatefulFrame state that was stored away would be thrown away as well. It's a pretty fundamental problem with the way we store the nsIStatefulFrame state attached to something that can possibly go away. Maybe Nisheeth has some ideas about this one - CC'ing him...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, sorry - just noticed there were two Davids. :) The last comment was aimed at David B.'s comments. David J., thanks for the clear testcase. I get the feeling that the changes to fix this bug would be non-trivial, and could potentially introduce regressions - risky this late in the game. I'd probably recommend rtm-.
Status: NEW → ASSIGNED
Based on Eric's comments that the fix would be non-trivial and we have very little time left, marking rtm-. Will have to fix it post-RTM, unfortunately.
As painful as this is to not be in the pipe for RTM, I understand the reasons why. I'm just curious as to the possibility of getting this into Netscape 6.01. This bug is costing me hours of lost productivity, not to mention a few looks from my co-workers not accustomed to the amount of cussing coming from my cube. Is there a way yet to nominate for RTM601? David
This bug is probably related to bug 34297 and a host of other bugs surrounding this same issue. Basically, when form controls are set to display:none, bad things happen in a lot of areas which are a real pain to work around...
Keywords: rtm → mozilla0.9, nsbeta1
QA Contact update
QA Contact: petersen → amar
Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Here's the activity log of target_milestone changes for this bug: 2000-10-10 13:58 ... --- (bug created) 2001-02-05 23:19:49 ... mozilla0.9.1 2001-04-30 15:00:39 ... mozilla0.9.2 2001-06-06 10:26:06 ... mozilla0.9.3 2001-07-24 14:54:16 ... mozilla0.9.4 Maybe the use of target_milestone values needs to be rethought.
Ok, now the target milestone of this bug has been set to mozilla1.0. Question: who is going to work on this before mozilla1.0? Eric?
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
*** This bug has been marked as a duplicate of 52334 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.