Closed
Bug 307821
Opened 19 years ago
Closed 19 years ago
Frameset handling broken, child pages can display as blank
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
VERIFIED
FIXED
People
(Reporter: jon, Assigned: mrbkap)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files, 1 obsolete file)
120 bytes,
text/html
|
Details | |
8.79 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909 Firefox/1.6a1 ID:2005090917
Here is probably as simple a frames page as one can have, reducing the Awstats
page yet still showing the rendering issue:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A frameset document</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
<FRAME src="http://www.google.com/">
<FRAME src="http://www.google.com/">
</FRAMESET>
</HTML>
The above will appear to load all the content, including the frame's "src"
pages, yet the frame elements will only render as blank.
The same issue also occurs should frame rows be used instead of cols. Curiously
though, should it be a "complex" frameset with rows and cols, expected behaviour
occurs again, with correct rendering:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A frameset document</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
<FRAMESET rows="*,200">
<FRAME src="http://www.google.com/">
<FRAME src="http://www.google.com/">
</FRAMESET>
<FRAME src="http://www.google.com/">
</FRAMESET>
</HTML>
All framesets worked correctly as of build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909
Firefox/1.6a1 ID:2005090903
... though appear to have broke after build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909
Firefox/1.6a1 ID:2005090916
Reproducible: Always
Steps to Reproduce:
1. Visit any page without nested frames, ie: all rows or all cols
2. "Child" elements of frameset (ie: frame), do not render and show up as blank
Actual Results:
Pages don't render...
Expected Results:
Render the child elements of frameset for "simple" framesets as it does with
"complex", nested framesets.
N/A
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
mrbkap, is this yours from bug 272702? DOMi says that the frames are children of
<head> rather than of the <frameset>.
Assignee: nobody → parser
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
Keywords: regression,
testcase
Product: Firefox → Core
QA Contact: general → mrbkap
Version: unspecified → Trunk
Assignee | ||
Comment 3•19 years ago
|
||
Certainly sounds like it. I'll try to figure out what's going on ASAP.
Assignee: parser → mrbkap
Assignee | ||
Comment 4•19 years ago
|
||
At least in terms of whether to put whitespace/userdefined tags in the head or
the "body" (not the head), framesets are equivilant to bodies.
Attachment #195512 -
Flags: superreview?(jst)
Attachment #195512 -
Flags: review?(jst)
Assignee | ||
Comment 5•19 years ago
|
||
Comment on attachment 195512 [details] [diff] [review]
Framesets are bodies too!
I really like to spam jst with these requests... This patch doesn't go quite
far enough for framesets, more comprehensive patch in a bit.
Attachment #195512 -
Attachment is obsolete: true
Attachment #195512 -
Flags: superreview?(jst)
Attachment #195512 -
Flags: review?(jst)
Assignee | ||
Comment 6•19 years ago
|
||
I noticed after I attached the last patch that we always wanted to use (_BODY |
_FRAMESET) in these sorts of tests. So I introduced a flag to indicate this.
This patch also fixes such gems as:
<framset>
<style></style>
<frame>
</frameset>
And
<frameset>
<meta>
<frame>
</frameset>
Attachment #195514 -
Flags: superreview?(jst)
Attachment #195514 -
Flags: review?(jst)
Assignee | ||
Comment 7•19 years ago
|
||
Comment on attachment 195514 [details] [diff] [review]
Fix even more cases
>+ if ((mFlags & NS_DTD_FLAG_HAS_MAIN_CONTAINER) ||
>+ mHeadContainerPosition == -1) {
This should test using &&. I've fixed it locally.
Comment 9•19 years ago
|
||
Comment on attachment 195514 [details] [diff] [review]
Fix even more cases
r+sr=jst
Attachment #195514 -
Flags: superreview?(jst)
Attachment #195514 -
Flags: superreview+
Attachment #195514 -
Flags: review?(jst)
Attachment #195514 -
Flags: review+
Comment 10•19 years ago
|
||
(In reply to comment #8)
> FWIW this bug exists on Linux builds too.
Just want to say that I experience the same problem in Camino as well...
Assignee | ||
Comment 11•19 years ago
|
||
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Comment 12•19 years ago
|
||
*** Bug 307922 has been marked as a duplicate of this bug. ***
Comment 13•19 years ago
|
||
Heh, too bad Tp is back at ~910ms again ;-).
Comment 14•19 years ago
|
||
*** Bug 307966 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 15•19 years ago
|
||
(In reply to comment #11)
> Fix checked into the trunk.
Confirm frames handling in both DOMi and visual inspection are fixed, tested in
build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050910
Firefox/1.6a1 ID:2005091017
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050910 Mozilla/1.0
Status: RESOLVED → VERIFIED
Comment 17•19 years ago
|
||
*** Bug 308263 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•