Summary: | [patch] javascript not loaded from another site, even if enabled on referring page | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Jonathan Marten <jjm> |
Component: | khtml ecma | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | grundleborg, kde, maksim, samuel.brack |
Priority: | NOR | ||
Version: | 4.5.4 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Patch to check script enable state agains correct host
Updated script enable patch Further updated patch |
Description
Jonathan Marten
2005-03-21 16:35:30 UTC
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. |