Closed Bug 64202 Opened 24 years ago Closed 20 years ago

HTML code generated by JavaScripts dishonour target attribute to the A tag

Categories

(Core :: DOM: Core & HTML, defect, P4)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: redhog, Unassigned)

References

()

Details

(Keywords: dom0, qawanted)

Attachments

(5 files)

HTML code dynamically generated by a JavaScript, which contains links (A-tags)
with a target frame attribute, dishonour this and allways open the page in a new
window. The same HTML code works fine if not generated by a JavaScript.
Can you please at least be more specific? I'm missing an example, thats why I
attach two files, after adding this comment. The first one, is an example frame
page. The second one writes an javascript generated html line with a link to
www.w3c.org. After selecting this link (in the top frame), the opening page is
loaded into the lower frame (bottom). I'm using target="bottom"  So I'm not sure
what you mean at this moment, but I will take a look to that url!
Sorry for being so brief. I have now created a minimal example at
http://foo.mini.dhs.org/mozillabug/
. The html.html is the static file demonstrating the correct behaviour. the
javascript.html is the dynamic, erraneous file. Strangely enought, I found,
after creating this minimal example, it does not err in exactly the same way /
instaed of opening the link in a new window, it does not open it at all (Note
that Netscape Navigator later than 4.01 (Think I got the version right) have
exactly the same bug, but errs in the same way for the mini-example too).
Stupid me, I took the wrong example. Because in this example the
<noframes></noframes> tags should go inside the <frameset></frameset> before
it's valid HTML. It's an testcase of some other bug. Sorry for that. Please
correct it, before using it.

Ok, I took a look at that site. And would like to say this to the reporter:
"Please consider to use an on-line validator". You may find one at:

http://validator.w3.org/  or at: http://www.htmlhelp.com/tools/validator/

Your frame page is using illegal HTML markup. And by correcting those errors,
I'm pretty sure that will do the trick! If not, just give us a clue.

O boy, mid air collision with the reporter, now I like to know who going first??
Smoke, you where first. Anyway, can you please make your testcases more visual.
Please use borders. And why should this work?? I don't see any document.write
statements in do you??
cc:ing before I lost trakc of this one, sorry for the spam.
Not JS Engine.  Moving to DOM0 although it sounds like either a content sink or
a frames issue.
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
This is the HTML (+ <BASE>) from the testcase "html.html" (works fine):


<!Doctype html public "-//W3C//DTD HTML 4.01 Frameset//EN">
<BASE HREF='http://foo.mini.dhs.org/mozillabug/'></BASE>
<Html>
 <Head>
  <Title>Foo</Title>
 </Head>
 <Frameset cols="220,*">
  <Frame name='left' src='left.html' scrolling=auto>
  <Frame name='right' src='main.1.html' scrolling=auto>
 </Frameset>
</Html>



This is the HTML(+ <BASE>) from "javascript.html" (DOESN'T work)

<!Doctype html public "-//W3C//DTD HTML 4.01 Frameset//EN">
<BASE HREF='http://foo.mini.dhs.org/mozillabug/'></BASE>
<Html>
 <Head>
  <Title>Foo</Title>
  <Script type="JavaScript" language="JavaScript">

   function genhtml()
   {
    document.write(   "<Html>\n"
                    + " <Body>\n"
                    + "  Dynamic left page<Br>\n"
                    + "  <A href='main.2.html' target='right'>Click                                                                                                                                                                                                                                                            
                                                              here</A><Br>\n"
                    + " </Body>\n"
                    + "</Html>\n");
   }

</Script>
 </Head>
 <Frameset cols="220,*">
  <Frame name='left' src='javaScript:top.genhtml();' scrolling=auto>
  <Frame name='right' src='main.1.html' scrolling=auto>
 </Frameset>
</Html>


NOTE: this HTML doesn't work in NN4.7, or in Mozilla.
      In NN4.7, I get this error in the JavaScript console:

                    JavaScript Error:
                    top.genhtml is not a function.


And the following page structure:

"Foo has the following structure:

     file:///(my local path)/javascript.html
          Frame: 
          Frame: http://foo.mini.dhs.org/mozillabug/main.1.html
"



Appearance: you see a vertical frame separator. The right frame ("main1")
is rendered correctly. The left frame is not rendered, and is solid grey.


In Mozilla (2000122105 WinNT), I see a frame separator for only a fraction 
of a second, and then the dynamically-written contents of the left frame
overwrite the entire page. The right frame disappears altogether.
That is, the end result is a page with NO frame separator, and only the 
contents of the dynamically-written left frame:

                    Dynamic left page
                    Click here


No errors appear in the JavaScript console.
The HTML doesn't work in IE4.7, either. I get this messagebox:


"An error has occured in the script on this page -

Line: 1
Char: 1
Error: Object does not support this property or method"
I tried removing the reference to ".top" in the src of the dynamic frame.
That is, I changed it from:

      <Frame name='left' src='javaScript:top.genhtml();' scrolling=auto>
to:   <Frame name='left' src='javaScript:genhtml();' scrolling=auto>



This didn't make things any better. I get a different error...
This HTML works in NN4.7 and IE4.7, but not in Mozilla:


<!Doctype html public "-//W3C//DTD HTML 4.01 Frameset//EN">
<BASE HREF='http://foo.mini.dhs.org/mozillabug/'></BASE>
<Html>
 <Head>
  <Title>Foo</Title>
 </Head>
 <Frameset cols="220,*">
  <Frame name=left src='javaScript: document.write("<Html>\n<Body>\nDynamic left 
   page<Br>\n<A href=main.2.html target=right>Click 
   here</A><Br>\n</Body>\n</Html>\n")'; scrolling=auto>
  <Frame name='right' src='main.1.html' scrolling=auto>
 </Frameset>
</Html>


That is, I put the document.write inline with frame src, instead of making
a function call to it. If you do this, you have to be careful to remove
all internal single quotes from the string inside document.write  
(e.g. replace 'main.2.html' with main.2.html and 'right' with right)



This HTML works in NN4.7 and IE4.7, but in Mozilla, I get this error 
in the JavaScript console:


              Error:        document has no properties
              Source file: 
              Line:         0
OK, I tried this HTML using top.document.write instead of document.write. 
NN4.7 CRASHES with it, but Mozilla does not:


<!Doctype html public "-//W3C//DTD HTML 4.01 Frameset//EN">
<BASE HREF='http://foo.mini.dhs.org/mozillabug/'></BASE>
<Html>
 <Head>
  <Title>Foo</Title>
 </Head>
 <Frameset cols="220,*">
  <Frame name=left src='javaScript: top.document.write(etc. etc.)';                                                                                                                          
                                                               scrolling=auto>
  <Frame name='right' src='main.1.html' scrolling=auto>
 </Frameset>
</Html>



Mozilla handles it the same way as I observed at 2001-01-03 13:03 above:


"
Appearance: you see a vertical frame separator. The right frame ("main1")
is rendered correctly. The left frame is not rendered, and is solid grey.


In Mozilla (2000122105 WinNT), I see a frame separator for only a fraction 
of a second, and then the dynamically-written contents of the left frame
overwrite the entire page. The right frame disappears altogether.
That is, the end result is a page with NO frame separator, and only the 
contents of the dynamically-written left frame:

                    Dynamic left page
                    Click here


No errors appear in the JavaScript console.
"
You did a lot of work Phil, but here's what I found in this new testcases:
1 - The <base> tag is not allowed within <html> it's only allowed within <head>.
2 - The <base> tag doesn't allow a closing tag.
3 - <Script type="JavaScript"... should be: <script type="text/javascript"...
4 - <frame src="" must point to a valid url (html document) it isn't an href=.
5 - change src= to valid html doc, in this case main.1.html.
6 - use <frameset cols="220,*" onLoad="genhtml()" to generate the new HTML document.
7 - if you want to replace the left document, then you need to use
parent.frames[0] for that document.write. Or the document get overwritten!
b.t.w. you can't test this, because of the DOM Property error 1010 (different
servers you know) but that's normal. Do you need a new working example, for this
case?? That can be done you know!
Because you can't see the result, here's my example.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frameset.dtd">
<html>
<head>
<base href="http://foo.mini.dhs.org/mozillabug/">
<title>Strike one</title>
<script language="JavaScript1.2" type="text/javascript">
<!--
function genhtml() {
var mydoc = parent.frames[0]; <!-- parent.frames[1] = right frame //-->
mydoc.document.write( '<html><head><title>Strike two</title></head><body>
Dynamic left page<br><a href="main.2.html" target="right">Click
here</a><br></body></html>' );
return;
}
//-->
</script>
</head>
<frameset cols="220,*" onLoad="genhtml()">
<frame src="main.1.html" name="left" id="left" scrolling="Auto">
<frame src="main.1.html" name="right" id="right" scrolling="Auto">
</frameset>
</html>

I just tested this on on our server, works fine. Hope this will help!
Just spoke to jst, who would like to take a look at this before
we close it. So for the time being, confirming bug  -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Phil, the problem here is that you are unable to use JavaScript functions, other
than the standard function defined by JS self! So you may and can generate a
line like <a href"www.foo.bar/foo.html" target="right"></a> without any
problems. But you can't use something like this:
href="javascript:javascriptFunction()" at this moment.

Note: first this bug was about the target attribute (target="") specified in an
generated HTML line, as you can see in the summary. A simple testcase will
demonstrate this functionallity in Mozilla, withour problem. So that aint the
real problem here!

Justin, you can't call javascript functions from the scr="" attribute. That's
the problem. You can do that from onLoad="" and from a valid HTML document, at
this moment. But we should be able to use src="javascript:javascriptFunction()",
right?
I was thinking, where did I see this before? Here on bugzilla is a bug filed
with exactly the same problem. I worked on that one for testcases. I can tell
you that the real problem is the fact that parent.frames[0].document doesn't
return an object but null, if you don't specify a valid HTML file.

So to be more specific you can call Javascript functions from the src attribute
right now, but then you need to specify 'javascript:parent.javascriptFunction()'
in the src attribute. But than you can't write to the frames[x], in this example
left and right.
Attached file Example/testcase
Reporter do you still see the problem with a new nightly build?
It seems that src="top.javascriptFunction()" is working, and so does
src="parent.javascriptFunction()". There was another bug with the same problem,
that one must be fixed!
This is still a bug. See the reduced testcase javascript.html
at 2001-01-03 09:43 above. It works fine in NN4.7, but not in Mozilla.


Using latest Mozilla binaries 20010125xx on WinNT, 20010126xx on Linux.
In Mozilla, on both platforms I get the error: 


            JavaScript error: 
            http://foo.mini.dhs.org/mozillabug/javascript.html line 8: 
            frames[0].document has no properties



The testcase works fine in NN4.7. At 2001-01-03 13:03 above I claimed
it didn't work in NN4.7, but I must have made some mistake -
*** Bug 66642 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.0
Keywords: dom0
Phil, jst, I think this is a dup of bug 22681. What do you think?
It's been a long time since I looked at this one. 
Fabian, is this a correct summary of what's not working?

this bug: 
            <FRAME  src='javascript: etc. etc.';> 

bug 22681:
            <IFRAME src='javascript: etc. etc.';> 


If so, we can leave it to jst to decide if the <FRAME> issue and
the <IFRAME> issue represent separate problems, or can be duped -
Yes the problem between frames and iframes is the same
(see jst's comments in duplicate bug 92557 on 2001-09-04 19:47)
However now I'm no longer so sure that bug 22681 is the real problem here.
I think it's just another bug that appeared in the testcase, but the real bug
(js-generated anchors with a target attribute dishonour that attribute) is still
there. I'm going to try to whip up a testcase.
In the meantime you could look at bug 67115 which has almost the same summary.
Wierd.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Can someone let me know if this is an example of the bug

Error: syntax error
Source File: http://www.geocities.com/hitokirimoogle/overlib.js
Line: 1
Source Code:
<HTML><HEAD><TITLE>Yahoo! GeoCities</TITLE>

If not where can I report this bug? Is there a dupe I could file a report in?
Severity = LOW [No Crash, There is functional failure, No Cosmetic failure]
Visibility = MEDIUM [Real world website usage could be there, Gets one point of 
compatibility with other browsers, since reporter says it used to work on older 
builds. gets one more point on compliance with adopted techonology, that is JS] 

Priority = Visibility * Severity

Priority = p4

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.
Keywords: qawanted
Priority: -- → P4
OOPS, Correction to my previous comments.

Visibility = MEDIUM [Real world website usage could be there, Gets one point of 
compatibility with other browsers, since I tested it with other brower & it 
works. gets one more point on compliance with adopted techonology, that is JS]
Target Milestone: mozilla1.0.1 → ---
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
*** Bug 67115 has been marked as a duplicate of this bug. ***
So as far as I can tell, this bug is invalid -- the JS in the javascript: url
should be running in the parent document, and hence the document.write should
happen in the parent document, as it does, no?
Marking invalid, per comment 34 and lack of objections.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: