Closed Bug 183683 Opened 22 years ago Closed 20 years ago

Support the ID attribute for FRAME/IFRAME/OBJECT

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sunrise_ey, Assigned: MatsPalmgren_bugz)

Details

(Keywords: testcase, xhtml, Whiteboard: XUL iframe => see bug 254284)

Attachments

(4 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530

HTML 4 defined the name attribute for the elements a, applet, form,  frame,
iframe, img, and map. Even though, in XHTML 1.0, name attribute is deprecated
and it is recommended to use 'id' attribute instead of 'name'.
So if there is a frame with an id attribute exists, for example :
   <frame src="r1.html" id="id_right" />
the following link should open 'r2.html' in the specified frame when clicked, 
   <a href="r2.html" target="id_right">  xxxx </a>

However, Mozilla does not support it. 


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attached file Example (obsolete) —
Oooops.. I cannot figure out how I can modify my first report...

Please download the example and open index.html in Mozilla.
Then try the two links in the upper frame.

When the target indicates the value of id attribute, 
a new window is opened.
->Layout:frames
Assignee: asa → frame
Component: Browser-General → Layout: HTML Frames
QA Contact: asa → amar
Not only is the name-attibute deprecated, the whole frameset-specification is
deprecated in xhtml. I don't know if using the id should work, but I wouldn't
worry about using name.
Attached file Testcase #1 (IFRAME)
As far as I understand XHTML 1.0 section 4.10, this is a valid bug.
http://www.w3.org/TR/xhtml1/#h-4.10

Boris?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase, xhtml
OS: Windows XP → All
Hardware: PC → All
Attachment #108340 - Attachment is obsolete: true
I guess this should be applied to HTML 4.01 as well, although not explicitly
mentioned in the specification.

Should it work for OBJECT elements?

If you look at the FRAMES[1] or IFRAME[2] Modules from the XHTML Modularization,
you will notice that NAME isn't defined as an optional attribute.

[1]<http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstract_modules.html#s_framesmodule>
[2]<http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstract_modules.html#s_iframemodule>
Yeah, for XHTML (but NOT HTML 4) this is valid.  

I think fixing the code at
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsFrameLoader.cpp#429
to look for "id" (instead of, not in addition to, "name") if the mOwnerContent
is an XHTML element (that is, if it's namespace is the XHTML namespace) is the
way to go...
I started looking at this a bit, for a XHTML document (like the testcase)
we have (at the point you suggested):

<iframe> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)
<p> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)
<body> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)
<html> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)

For the corresponding HTML document we have:

<iframe> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)
<p> IsContentOfType(eELEMENT eHTML), GetNameSpaceID(kNameSpaceID_XHTML)
NULL!

This is looking at 'mOwnerContent' and its parents.
Suggestions?
This is the culprit, rev. 1.222 of nsGenericHTMLElement.cpp:

void
nsGenericHTMLElement::GetNameSpaceID(PRInt32* aID) const
{
  // XXX
  // XXX This is incorrect!!!!!!!!!!!!!!!!
  // XXX
  *aID = kNameSpaceID_XHTML;
}

So, would it be correct to just remove that and go with kNameSpaceID_None
for plain ol' HTML?
No, that would break html.css.

Get the namespace ID off the nodeinfo, not off the nsIContent.  That should do
the trick.
(In reply to comment #10)
> void
> nsGenericHTMLElement::GetNameSpaceID(PRInt32* aID) const
> {
>   // XXX
>   // XXX This is incorrect!!!!!!!!!!!!!!!!
>   // XXX
>   *aID = kNameSpaceID_XHTML;
> }

What's wrong with it?  I certainly haven't seen any spec that makes it incorrect
(assuming this is used for things detectable by authors).
Yes, I just realized that myself... feels a bit wallpaperish though...
IMO, it is ugly that
content->GetNodeInfo() != content->GetNodeInfo()->NamespaceID()
oops, I meant
content->GetNameSpaceID() != content->GetNodeInfo()->NamespaceID()
Attached patch Patch rev. 1 (obsolete) — Splinter Review
Something like this perhaps...
Comment on attachment 155119 [details] [diff] [review]
Patch rev. 1

Forget that, need to remove NAME lookup too...
Attachment #155119 - Attachment is obsolete: true
Attached patch Patch rev. 2 (obsolete) — Splinter Review
Attached file Testcase #2 (FRAME)
Attachment #154992 - Attachment description: Testcase → Testcase #1 (IFRAME)
Do we really want to use "id" for XUL iframes?  Or do we want to use "name" for
those?

I'm not sure what the XUL spec says on this, if anything.  The XULPlanet docs
mention nothing about the "name" attribute of <xul:iframe>, so perhaps we do
want to switch those to using "id".
How about applet names? 
http://www.w3.org/TR/REC-html40/struct/objects.html#edef-APPLET
"name = cdata [CS]
    This attribute specifies a name for the applet instance, which makes it
possible for applets on the same page to find (and communicate with) each other."

I think that maps to AppletContext::getApplet(String name) which I assume should
be able to find <applet id="not_name"> in a XHTML document?
http://java.sun.com/j2se/1.3/docs/api/java/applet/AppletContext.html
(or is this all done within the JRE itself?)
<applet> can't be a link target "since it's not a frame"....
Sure, but http://www.w3.org/TR/xhtml1/#h-4.10 talks about "fragment
identifiers" in general so I supposed "applet lookup" would be covered by that.
But applets are deprecated anyway so let's not bother with that...
(In reply to comment #19)
> Do we really want to use "id" for XUL iframes?
> Or do we want to use "name" for those?

Yes, this patch would break quite a lot of mailnews actually, e.g:

mailnews/base/resources/content/messenger.xul:
     <iframe name="accountCentralPane" flex="1" src="about:blank"/>

mailnews/base/resources/content/mailWindow.js:
window.frames["accountCentralPane"].location = acctCentralPage;

When opening Mail I get:
Error hiding AccountCentral page -> TypeError: window.frames.accountCentralPane
has no properties

So, maybe we should reverse the if-condition and do "id" for XHTML and
"name" for the rest? (for now at least)
Yeah, let's do the safe thing for now and file an XPFE bug to decide what the
right behavior for XUL is.

I'm really rather unhappy that people are using this DOM0 stuff in our chrome... :(
Attached patch Patch rev. 3Splinter Review
Assignee: core.layout.html-frames → mats.palmgren
Attachment #155120 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #155141 - Flags: superreview?(dbaron)
Attachment #155141 - Flags: review?(bzbarsky)
Comment on attachment 155141 [details] [diff] [review]
Patch rev. 3

r+sr=bzbarsky; file that bug on XPFE and cc at least Neil, myself, jst, ben
goodger, I guess?  Not sure who should be deciding what XUL should do; if you
think of people who would care, cc them.
Attachment #155141 - Flags: superreview?(dbaron)
Attachment #155141 - Flags: superreview+
Attachment #155141 - Flags: review?(bzbarsky)
Attachment #155141 - Flags: review+
Wouldn't it have been better to fix mailnews? I skimmed the source and could not
find any other frames that were accessed by name but did not have an id.
(Filed bug 254284 on the XUL iframe issue)
Attached file Testcase #3 (OBJECT)
Will this be supported as well?
QA Contact: amar → ian
Summary: When a link is clicked, Mozilla does not open the new page at the specified target frame if the given target is an 'id' instead of 'name' → Support the ID attribute for FRAME/IFRAME/OBJECT
Checked in 2004-09-12 16:34 PDT

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: XUL iframe => see bug 254284
*** Bug 268777 has been marked as a duplicate of this bug. ***
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.

Attachment

General

Creator:
Created:
Updated:
Size: