using CSS display: xxx on IFRAMES causes data loss

RESOLVED DUPLICATE of bug 52334

Status

()

P3
critical
RESOLVED DUPLICATE of bug 52334
18 years ago
3 months ago

People

(Reporter: djoham, Assigned: eric)

Tracking

({dataloss, html4})

Trunk
mozilla1.0
x86
Linux
dataloss, html4
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 16684 [details]
HTML source for the IFRAME
(Reporter)

Comment 2

18 years ago
Created attachment 16685 [details]
Test case

Comment 3

18 years ago
html frames
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?
(Reporter)

Comment 6

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

Comment 8

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

Comment 9

18 years ago
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.
Whiteboard: [rtm-]
(Reporter)

Comment 11

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

Updated

18 years ago
Blocks: 7954
(Reporter)

Comment 12

18 years ago
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
Whiteboard: [rtm-]

Updated

18 years ago
Target Milestone: --- → mozilla0.9.1

Comment 13

18 years ago
QA Contact update
QA Contact: petersen → amar
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.

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 15

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

Updated

18 years ago
Target Milestone: mozilla0.9.4 → mozilla1.0
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

Updated

17 years ago
Blocks: 104166

*** This bug has been marked as a duplicate of 52334 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Updated

3 months ago
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.