Closed Bug 86349 Opened 23 years ago Closed 23 years ago

Frame bug - hidden value doesn't show

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla0.9.7

People

(Reporter: galfandary, Assigned: harishd)

References

(
URL
)

Details

The following set works with both IE5 and Netscape4:

bug.htm:
==========
<html>
<head>
<title>Frame bug</title>
<form name=ff><input type=hidden name=vv value=MyHiddenValue></form>
</head>
<frameset rows=50,50>
  <frame name=jscript1 src=bug_frame.htm>
  <frame name=jscript2 src=bug_frame.htm>
</frameset>
</html>
==========

bug_frame.htm:
==========
<html>
<body onload=javascript:document.ff.vv.value=top.document.ff.vv.value>
<form name=ff>
<input type=text name=vv>
</form>
</body>
</html>
==========

With Mozilla0.9.1 the value (MyHiddenValue) doesn't show.
Component: DOM HTML → HTMLFrames
Why should this work? You can use the following code instead:
bug.htm:
==========
<html>
<head>
<title>Frame bug</title>
<script>var ff="MyHiddenValue"</script>
</head>
<frameset rows=50,50>
<frame name=jscript1 src=bug_frame.htm>
<frame name=jscript2 src=bug_frame.htm>
</frameset>
</html>
==========

bug_frame.htm:
==========
<html>
<body onload="document.ff.vv.value=top.ff">
<form name=ff>
<input type=text name=vv>
</form>
</body>
</html>
==========

I suggest to resolve this INVALID or WONTFIX, but leave the decision to others.
Severity: critical → minor
My way gives C++ access via the public DOM interfaces.
AFAIK there are no public C++ interfaces to access JS vars.
BTW the fact that this works with both IE5 and NS4 gives
some indication that this SHOULD work ...
Severity: minor → critical
setting status to NEW.  _But_, <form> is not a valid tag in <head>.  The error
condition of dropping the value of that input element is a fairly reasonable one....

You could use a <META> tag for that value.  That's what <META> tags are for, you
know....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, my friend, this is even worse. Using <meta> for the job
only works with IE5 but not with either NS4 or Mozilla :-(

The <form> tag in the header DOES work with Mozilla too
if it's in the same frame so, this seems like a definite frames bug.
 Changing the QA contact
QA Contact: stummala → amar
The <FORM> is inaccessible not only because it is in the head, but because it is
in a frameset document. A frameset document cannot have a body, thus the frame
is discarded. In the case where it is in the head on the same page, the body
exists and the frame is interpreted like it is part of it.
 I am not sure how to use meta tags to pass the data, but if it is a bug then it
should be filed separately. I think this issue is INVALID.
I'm fine with marking this INVALID, but I do think we've bent over backwards
before to make forms work to some extent in frameset documents (for backwards
compatibility), but I don't have the details on that. Reassigning to harishd,
Harish, anything easy we can do about this in the parser/sink? If not, I vote
for WONTFIX.
Assignee: jst → harishd
--> 0.9.7
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
jst: I'm getting a JS error

Error: top.document.ff has no properties


Harishd, that means the sink never sees

  <form name=ff><input type=hidden name=vv value=MyHiddenValue></form>

I'm not saying that this is something that must be fixed, but if we can we should...

jst: We did bend our backs to fix type != hidden case. Fixing this bug is not
trivial and I don't think we should bend our backs further to fix the malformed
content.

Marking WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
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.