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.

html frames

Nominating for RTM since as per description, this can cause dataloss.

So is the basic problem here that we're attaching data to frames that should be attached to the DOM?

David, I'm not sure I understand your question, so let me re-phrase my issue and see if that helps. The real issue is that when you set the display style of the IFRAME back to "block", the IFRAME reloads. Any data that you had stored in the contents of the IFRAME (IE javascript variables) or any display attributes you had (say filled in text boxes) is unrecoverably lost. Does that help? David J.

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

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

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

QA Contact update

See also bug 52334 "Problems with contentDocument and 'display:none' in IFRAMES." jst's comment about the relationship between that bug and bug 34297: > The form control and frame problems might appear similar but they are > unrelated.

Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.

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.

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