Version: 3.5.2 (using KDE 3.5.2, Debian Package 4:3.5.2-2+b1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15-1-k7 May be related to bug 27988 http://bugs.kde.org/show_bug.cgi?id=27988 Normally, creating a function in the global scope should create a child of the window object. Thus, you can assign an onload event handler to the windows object just by doing this (currently only FF does this correctly): function onload(){alert('onload called')} Konqueror doesn't understand it. Worse, if you first assign an onload with window.onload=function(){...}, it will call none of the two: onload=function(){alert("onload1");} //should display an alert function onload (){alert('onload2')}; alert("This is the onload function registered: \n\n"+window.onload); Simple testcase: http://ministeyr.free.fr/testcases/test_onload.htm Then it will display that the onload function registered is the first one, but call neither when the page is loaded. Note that Firefox, Opera and Konqueror all behave in a wrong way here.
I have the same problem as well on FC6 with Konqueror 3.5.6 & KDE 3.5.6 The following piece of javascript code does not get executed after the window.onload event fires: function onPageLoad(newAction) { if ('function' == typeof window.onload) { var prevActions = window.onload; window.onload = function() { prevActions(); newAction(); } } else { window.onload = newAction; } } adding a function to be executed with this code after the onload event fires does not work. The above anonymous function assigned to the window.onload property should allow several functions to be queued for running after the page loads. This works OK in FF 1.5.0.10 - nothing happens at all in Konqueror. onPageLoad(firstFunc); onPageLoad(secondFunc); onPageLoad(thirdFunc); should allow those three functions to executed in that order after the page has loaded. Obviously the functions need to exist in a javascript file used by the page. Sorry I don't have a URL to point you to just now. But you can test this out by copying the above function to your own JS file locally.
Created attachment 20540 [details] Test files to prove this works OK. just copy the three files into a directory under your webserver root, and load onPageLoad.php into Konqueror, Firefox, etc.
Created attachment 20541 [details] javascript containing the onPageLoad function
Created attachment 20542 [details] seperate javascript file to use the onPageLoad function
The above attachments prove that the window.onload event is actually working correctly in Konqueror. I t also works OK in Firefox, IE 7.0, 6.0, 5.5 & 5.0. The problem appears to be using console.log messages in a javascript function for Firefox Firebug debugger. Having removed those console.log messages all works well now!
For first testcase: Firefox's handling of function declarations is incredibly broken, and is not ECMA 262-3 compliant. Konqueror's is correct in this case (but buggy in some others), as are those in IE and Opera. If you say: function onload() { } You are /declaring/ onload to be a local variable, which is initialized to the function as you start executing the scope. Hence, any assignment of window.onload merely changes the local value. (And locals generally shadow the dynamic properties in window object, though perhaps this is a special case). So when you say: onload = function() {} function onload() { ... } the 'function onload' stuff gets handled /first/ in standards-compliant browsers. What you want to do is simply use onload = function () {} consistently, and it'll work just fine everywhere. (Since Mozilla brokenly interpreters function onload() as onload = function() ..) Re: comment #5 and on: so it's fine for your stuff?
do you still have this problem in konq 4?
I've not tested this yet in K4 yet. Not doing any JS coding right now.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it was reported on an older version, can we please ask you to see if you cazn reproduce the issue with a more recent software version? If you can confirm this issue still exists in a recent version, please change the version field and the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!