Version: 3.5 (using KDE 3.5.0, compiled sources) Compiler: gcc version 3.4.4 [FreeBSD] 20050518 OS: FreeBSD (i386) release 6.0-RELEASE Example: <html> <body> <iframe id="visible"></iframe> <iframe style="display:none" id="hidden"></iframe> <a href="http://www.google.com/" onclick="document.getElementById('visible').contentDocument.location.href='http://www.kde.org/'; return false">Replace visible</a><br> <a href="http://www.google.com/" onclick="document.getElementById('hidden').contentDocument.location.href='http://www.kde.org/'; return false">Replace hidden</a> </body> </html> I see here two bugs: 1. ECMAScript does not see and/or can not assign hidden element's properties. 2. ECMAScript nor ignores error, nor returns false in case of error, hense "onclick" returns true and <a> follows its href.
Bug confirmed on KDE 3.5.5 / Kubuntu 6.10. Example test case available give above now available online at http://www.mutube.com/x/kde/bug120820.html This bug seems to be related to #71809 although I have been unable to reproduce the visible/hidden difference mentioned on that bug.
KDE 3.5.5 / FreeBSD 6.2-RC2. > I have been unable to reproduce the visible/hidden difference Browser should visibly do nothing when "Replace hidden" is clicked but goes to google instead. The problem is iframe object has no contentDocument property when hidden. Simple test case: <html> <body> <iframe id="test"></iframe><br> <a href="#" onclick="object=document.getElementById('test').contentDocument; alert(object); return false">Get object</a> | <a href="#" onclick="document.getElementById('test').style.display='none'; return false">Hide iframe</a> | <a href="#" onclick="document.getElementById('test').style.display=''; return false">Show iframe</a> </body> </html> 1. Click 'Get object'. Note alert text. Looks good. 2. Click 'Hide iframe'. 3. Click 'Get object'. Note alert text. 'null' in my case. 4. Click 'Show iframe'. 5. Click 'Get object'. Note alert text. Looks good. 6. Compare with Mozilla
The visible/hidden difference I can't reproduce is in the /other/ bug not this one! This bug's behaviour agreed & confirmed.
*** This bug has been marked as a duplicate of 71809 ***