Version: (using KDE KDE 3.5.7) Installed from: Mandriva RPMs OS: Linux Konqueror 3.5.7 fails many of the DOM tests from http://www.w3.org/DOM/Test/ Konqueror was the 1st to pass Acid2 and CSS3 test, but has serous problems with ECMAscript. this test suit once passed 100% should make konqueror are cool browser.....
We already use this testsuite, though at older version, and via our native runner; and most things that don't pass are due to questionable tests, IIRC. Could you please elaborate on the problems you're seeing? I imagine it's just JsUnit not working; I'll look into that, but last time I did I was frustrated by its number of browser-specifities, IIRC. (And I would appreciate it if you dropped comments on ECMAScript support --- we implement it far more compliantly than some other open-source browsers out there.)
*** Bug 150504 has been marked as a duplicate of this bug. ***
Sorry for ECMA script comment; don't get me wrong, konqueror is my default browser and I like it so much I'd like to see it more spread. The fact is that eventhough ECMA implementation is better than other browsers, the current DOM implementations doesn't include sufficient support for many web sites (either w2 standard or microsoft centric). As a result, many distro put firefox as default browser in KDE desktop which is awfull IMHO but a reality (Mandriva is one of them). this is because some sites are better rendered under Firefox which deals better with DOM used in those sites eventhough its CSS implementation is far less good than konq' one.
You would have to be more specific. Vague comments don't help us fix stuff.
Please name specific tests that fails, which works in at least two other browers. I can only get the tests to run by spoofing as Firefox :(
The problem is not to compare konqueror to other browsers bad or incomplete implementation. The problem is to have konqueror pass the tests. BTW, is it so difficult to go to the page I gave and run some tests. Doing that will show that no tests passes. In fact the scripts abort before running the 1st test as of konqueror 4.5.68.... Example: http://www.w3.org/2004/04/ecmascript/jsunit/testRunner.html?testpage=http://www.w3.org/2004/04/ecmascript/level1/core/alltests.html&implementation=iframe&skipIncompatibleTests=true&autoRun=true&contentType=text/html No to say that most thoses tests passes on opera 10.20 and firefox 4.0b6 (thow they have errors, there are few and they are minor).
ECMAScript test on page http://www.w3.org/DOM/Test/ don't even load. KDE 4.5.76 (4.6 >= 20101111) (Mandriva RPM) java and javascript activated.
Olivier, I agree with you that the ECMAScript test page does not load. Have you tried to reach edward(at)jsunit.net to report this problem? I have on March 30th 2010 and have just done it a min ago today (I have +CC-ed you). If sufficient people would do that, then we would increase chances to get that problem fixed. regards, Gérard
It does indeed need fixing on their end. The test driver has a UA-sniffed workaround for us that actually breaks the site. See the 'isKonqueror' variable in jsUnitSetOnLoad. That makes it use .onload and not listeners, so the 'page loaded' thing does not run for us, as there is a body onload= as well which overrides it. Load the page with a UA spoof as firefox, and it will run.
Olivier and Maksim, I have contacted Edward Hieatt. > See the 'isKonqueror' variable in jsUnitSetOnLoad. That makes it use .onload > and not listeners, so the 'page loaded' thing does not run for us, as there is > a body onload= as well which overrides it. Right. Load http://www.w3.org/2004/04/ecmascript/jsunit/app/jsUnitCore.js and then examine around line 396 function jsUnitSetOnLoad(windowRef, onloadHandler) { var isKonqueror = navigator.userAgent.indexOf('Konqueror/') != -1 || navigator.userAgent.indexOf('Safari/') != -1; if (typeof(windowRef.attachEvent) != 'undefined') { // Internet Explorer, Opera windowRef.attachEvent("onload", onloadHandler); } else if (typeof(windowRef.addEventListener) != 'undefined' && !isKonqueror){ // Mozilla, Konqueror // exclude Konqueror due to load issues windowRef.addEventListener("load", onloadHandler, false); } else if (typeof(windowRef.document.addEventListener) != 'undefined' && !isKonqueror) { // DOM 2 Events // exclude Mozilla, Konqueror due to load issues windowRef.document.addEventListener("load", onloadHandler, false); } else if (typeof(windowRef.onload) != 'undefined' && windowRef.onload) { windowRef.jsunit_original_onload = windowRef.onload; windowRef.onload = function() { windowRef.jsunit_original_onload(); onloadHandler(); }; } else { // browsers that do not support windowRef.attachEvent or // windowRef.addEventListener will override a page's own onload event windowRef.onload=onloadHandler; } } -------------- var isKonqueror = navigator.userAgent.indexOf('Konqueror/') != -1 || navigator.userAgent.indexOf('Safari/') != -1; Interestingly, Safari is put into the same bag here: maybe Safari does not run the test suite either for the same reasons. -------------- I *know* Konqueror 4.5+ supports windowRef.addEventListener and I think Konqueror 3.5.x supported it too. if (typeof(windowRef.addEventListener) != 'undefined' && !isKonqueror){ // Mozilla, Konqueror // exclude Konqueror due to load issues What were those load issues? For which version of Konqueror? If those load issues were fixed a long time ago, then this chunck: && !isKonqueror could be removed ------------ Another thing in that function is that you usually want to start with DOM compliant code and then fork for proprietary methods, not the reverse order. E.g.: if(windowRef.addEventListener) // DOM 2 Events compliance { ... } else if(windowRef.attachEvent) // IE8 and lower; Opera 7 and lower { ... }; regards, Gérard
Comments from Edward Hieatt in 2 emails today: " Hi, Sorry you're running into a problem. JsUnit is no longer actively maintained, although we can merge in a pull request if you like. See http://jsunit.net for details. Edward Hieatt " " On GitHub, a "pull request" is the term used to describe the action where a contributor makes a change to a codebase on his own branch and then requests that the author "pull" the change in. So no, I wasn't referring to money - I was saying that if you have the ability to make a change yourself, I'd be happy to incorporate it. Edward Hieatt " regards, Gérard
Olivier and Maksim, The DOM Level 1 Test Suite has been ported to start from this page: http://www.w3.org/2007/03/dom-tests/intro so that it can be used for mobile devices. I just tried it with Konqueror 4.6.1 and it worked without a problem: Just click the link "Start the test suite [1]" at the bottom of the page. This is the score result I got: Mozilla/5.0 (compatible; Konqueror/4.6; Linux 2.6.35-28-generic-pae; X11; i686; fr) KHTML/4.6.1 (like Gecko) Kubuntu: 238 results, 100% All results are available at http://www.w3.org/2007/03/mth/results?ts=dom1 There are other DOM test suite webpages available for testing Konqueror 4.6+ . regards, Gérard
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? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change 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!