(*** This bug was imported into bugs.kde.org ***) Package: kjs Version: KDE 2.2.2 Severity: normal Installed from: SuSE RPMs Compiler: gcc 2.95.3 OS: Linux OS/Compiler notes: Not Specified referencing to another frame via parent.frame1.document.writeln('Hello World!!!'); don't works! With Opera/Ns4.7-6 works fine! Here the Html-Code (3 files): index.html: <frameset rows="50%50%"> <frame name="frame1" src="1.html"> <frame name="frame2" src="2.html"> </frameset> 1.html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title></title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Quanta Plus"> </head> <body> frame 1 </body> </html> 2.html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title></title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Quanta Plus"> </head> <body> frame 2 <script language='JavaScript'> <!-- parent.frame1.document.open(); parent.frame1.document.writeln('Hello World!!!'); parent.frame1.document.close(); //--> </script> </body> </html> (Submitted via bugs.kde.org)
Works not, but sometimes (50%) the "frame 1" doesn't disappear and "Hello World!!!" is added to it, despite the open() call.
This is a timing problem. There's no guarantee that frame1 will be loaded before frame2 will be. So half of the time frame1 is loaded first (and it sort of works, but its tokenizer is still running, I guess that's why the string is appended), half of the time frame2 is loaded first (and the loading of frame1 will conflict)... If you use <frameset rows="50%,50%" onload="frame2.doit()"> in index.html and <script language='JavaScript'> function doit() { parent.frame1.document.open(); parent.frame1.document.writeln('<P>Hello World!!!</P>'); parent.frame1.document.close(); } </script> in 2.html, then it all works as expected. Another way would be to simple use <frame name="frame1" src=""> so that there's nothing to load for it. (This might only work with Konqueror-3.1-rc2 and later though). I think there's nothing to fix wrt the timing issue. However the fact that <P> is needed might be a bug. Not sure there. I guess this is only a problem in this testcase, not in the real world usage you wanted to test anyway..... Can you give more information? Is the above "workaround" enough, or should I reassign this as a tokenizer bug because it only works with <P>?
Ouch, this crashes sometimes with KDE CVS HEAD. (gdb) p m_object $1 = (class RenderObject *) 0x0 (gdb) bt #0 0x41b59cc3 in khtml::RenderLayer::height() const (this=0x8458664) at /mnt/devel/kde/kdecvs/kdelibs/khtml/rendering/render_layer.cpp:149 #1 0x41b7dd6b in khtml::RenderCanvas::docHeight() const (this=0x8458510) at /mnt/devel/kde/kdecvs/kdelibs/khtml/rendering/render_canvas.cpp:612 #2 0x41b7c767 in khtml::RenderCanvas::layout() (this=0x8458510) at /mnt/devel/kde/kdecvs/kdelibs/khtml/rendering/render_canvas.cpp:157 #3 0x41a867f0 in KHTMLView::layout() (this=0x83f1438) at /mnt/devel/kde/kdecvs/kdelibs/khtml/khtmlview.cpp:571 #4 0x41b7cd3c in khtml::RenderCanvas::close() (this=0x8458510) at /mnt/devel/kde/kdecvs/kdelibs/khtml/rendering/render_canvas.cpp:288 #5 0x41adda3e in DOM::DocumentImpl::close() (this=0x844ec30) at /mnt/devel/kde/kdecvs/kdelibs/khtml/xml/dom_docimpl.cpp:1124 #6 0x41b14184 in DOM::HTMLDocumentImpl::close() (this=0x844ec30) at /mnt/devel/kde/kdecvs/kdelibs/khtml/html/html_documentimpl.cpp:292 #7 0x41c4fb66 in DOM::HTMLDocument::close() (this=0xbfffde30) at /mnt/devel/kde/kdecvs/kdelibs/khtml/dom/html_document.cpp:201 #8 0x41bd0931 in KJS::HTMLDocFunction::tryCall(KJS::ExecState*, KJS::Object&, KJS::List const&) (this=0x843ed78, exec=0xbfffe1e0, thisObj=@0xbfffdf90, args=@0xbfffdfe0) at /mnt/devel/kde/kdecvs/kdelibs/khtml/ecma/kjs_html.cpp:93 #9 0x41bb5416 in KJS::DOMFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (this=0x843ed78, exec=0xbfffe1e0, thisObj=@0xbfffdf90, args=@0xbfffdfe0) at /mnt/devel/kde/kdecvs/kdelibs/khtml/ecma/kjs_binding.cpp:109 #10 0x41d7ee36 in KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (this=0xbfffdfc0, exec=0xbfffe1e0, thisObj=@0xbfffdf90, args=@0xbfffdfe0) at /mnt/devel/kde/kdecvs/kdelibs/kjs/object.cpp:69 #11 0x41d466bd in KJS::FunctionCallNode::evaluate(KJS::ExecState*) const (this=0x844b7d8, exec=0xbfffe1e0) at /mnt/devel/kde/kdecvs/kdelibs/kjs/nodes.cpp:843 #12 0x41d4c02f in KJS::ExprStatementNode::execute(KJS::ExecState*) (this=0x844b7f0, exec=0xbfffe1e0) at /mnt/devel/kde/kdecvs/kdelibs/kjs/nodes.cpp:1945 #13 0x41d52898 in KJS::SourceElementsNode::execute(KJS::ExecState*) (this=0x844abb0, exec=0xbfffe1e0) Reassigning to renderer
Still valid with HEAD. Testcase: http://www.affenschlaffe.de/kde-bugs/37007_frame.html
This still seems to be reproducible on svn trunk r793457. Using the testcase here: http://www.grundleborg.com/kde/bugsquad/testcases/37007 , about 50% of the time I see the text "frame 1" and the remaining times the frames both stay blank.
Created attachment 24216 [details] testcase uploading test case
inde kde 4.2.4 I only get a blank side or "frame 1" text, in kde 3.5.10 I got either a blank side or "frame 1" or "frame 1 hello world" so it lookes like the bug is still present
In 4.5.4 it's still like described in Comment #7; I get either a totally blank site or the text "frame 1". Updating version.
Thank you for the bug report. As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.