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)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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)

Testcase #1 (IFRAME)
533 bytes, application/xhtml+xml
Details
Testcase #2 (FRAME)
759 bytes, application/xhtml+xml
Details
Patch rev. 3
1.09 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Testcase #3 (OBJECT)
297 bytes, application/xml
Details
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. 3 — — Splinter 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: