Version: (using KDE KDE 3.4.0) Installed from: Compiled From Sources OS: Linux Some sites load JavaScript from another server, via a <SCRIPT SRC=..."> tag. One of these is, for example, www.allofmp3.com; it loads a script library by doing: <!-- extracted from http://www.allofmp3.com/index2.shtml --> <SCRIPT LANGUAGE="JavaScript" SRC="http://195.96.170.29/js/script_site.js" TYPE="text/javascript"> </SCRIPT> The problem is that if JS is disabled globally but enabled locally for the referring page (I currently have it enabled for domain .allofmp3.com). Even with this setting, the script is not loaded because the host-specific JS check is done against the script URL's host (195.96.170.29 above) in DocLoader::requestScript(). Unfortunately what the user will get is non-working JS even though it is apparently enabled, with no error indication unless script debugging is turned on. Surely this check should be done against the containing page's URL? After all, the obvious meaning for the user should be "run JavaScript when I'm viewing content from this server", not "run JS if it originates from this server". There is a subtle difference. There is obviously a workaround - also enable host-specific JS for 195.96.170.29 - but this isn't a satisfactory solution because it needs the user to (a) understand HTML; (b) know where to look and (c) what to do.
Created attachment 10235 [details] Patch to check script enable state agains correct host This patch checks the JS enabled policy against the host of the containing page, not the host of the script URL. With this patch, JS appears to work correctly on the site quoted with no errors reported in the debugger.
But that would make the whole pr. script check redundant. It's there to *prevent scripts being loaded from hosts for which javascript is denied*. A possible solution would be to change the policy check (isJavaScriptEnabled()) to handle this situation, that is allow the script if the site is not explicitly denied that right in such cases.
I'm sure that the JS security policy has been very carefully thought through, and one can't be too careful where security is concerned. However, it's no good having a secure browser if it does not work on sites which the user needs to visit, and that is exactly what happens on this site. Even worse, there is no indication of why the scripting doesn't work and no obvious way to enable it; as far as the average user can tell JS should work because the menu option is ticked, so their only logical conclusion would be that Konqueror is not working. Anders' suggested solution is reasonable; will try to code it and verify.
Created attachment 10504 [details] Updated script enable patch Implemented check as suggested in comment #2. Unfortunately it doesn't seem to be possible to find out if a host is explicitly disabled using the existing logic in khtml_settings: there is no distinction between "globally enabled and no explicit setting for this host" and "globally disabled but enabled for this host". So I've added a new test KHTMLSettings::isJavaScriptExplicitlyDisabled(), which checks for a reject configured for that specific host only. Both tests are then applied in the loader.
Created attachment 13737 [details] Further updated patch Still appears to be a problem with this site and KDE 3.5.0. Patch updated for that version.
*** Bug 130779 has been marked as a duplicate of this bug. ***
Assinging the bug to khtml ecma, since it's a case for the JS developers and updated version to 4.5.4
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.
Test case no longer applies. But KHTML is deprecated anyway, nut sure whether the problem happens with other HTML viewing parts.