Bug 49145

Created attachment 229 [details]
first patch, khtml side only

This patch modifies khtml_settings.{cc,h} and ecma/kjs_window.cpp so that khtml
correctly reads and interprets global as well as per-domain settings.

I introduced a new KPerDomainSettings struct which contains all per-domain
settings. One object is directly embedded in KHTMLSettingsPrivate serving as
default (global domain) whereas the others are inserted into the domainPolicy
map as specified by the configuration.

setup_per_domain_policy serves as a KPerDomainSettings constructor for the
legacy keys JavaScriptAdvice, ECMADomainSettings and JavaDomainSettings. It
returns an existing domain policy or creates a new one by inheriting from the
global domain.

readDomainSettings reads the settings of the given domain from the config file
and writes them into the relevant domain policy. The global domain policy will
also be set from this method, when the global parameter is true. This method
takes care of inheriting from the global domain or in case of the global
domain, using the hardcoded default, if the key does not exist. That means that
all domain policies are fully initialized after reading and all values
computed. No more inheriting needs to be done when a domain policy is queried
later on.

init now uses readDomainSettings to initialize the global domain as well as all
domains given under the new key DomainSettings. It also handles legacy keys,
but I still haven't tested them, so don't trust that code yet. DomainSettings
is a simple string list, containing nothing but domain names.

I extended lookup_hostname_policy to return KPerDomainSettings references
instead of simple boolean values. The handling remains the same, though I
optimized lookup a bit by using iterators wherever possible.

The new getters are:
KJSWindowVVVPolicy windowVVVPolicy(const QString &hostname=QString::null) const

where VVV is one of Open, Resize, Move, Focus, Status.
They simply return the requested member from the appropriate domain policy.

I also adapted the implementations for isJavaEnabled, isJavaScriptEnabled,
isPluginsEnabled and noticed that they'd better be const, but refrained from
changing it for not breaking BC.

Well, within kjs_window.cpp I inserted the relevant queries to the settings
object. The code's obvious so no need to dwell upon it.

Btw, I also implemented per-domain handling of isJavaEnabled and
isPluginsEnabled; it would have been harder to ignore than to implement ;-)

I used enums for the policies and each enum contains a KJSWindowVVVInherit=-1.
This value is nowhere needed now and intended to be used within the kcontrol
module.

A little problem are the bitfields in KPerDomainSettings. g++ insists that
bitfields are signed, thus returning -1 for 3 in KJSWindowOpenPolicy, for
example. I inserted a small hack to circumvent this (the other locations happen
to work fine because I always test for equality to 0). If anyone has a cleaner
idea, please tell me.

This patch is not intended to be included within KDE, and serves merely a draft
ready to be commented upon.

Created attachment 362 [details]
second patch, khtml side only

It was time for a new patch, the old bitrotted away in no time.

Besides this patch fixes the Window::Open g++ hack because the Inherit
enumeration constants now use 32767 instead of -1.

Created attachment 542 [details]
third patch, khtml side only

Some minor improvements:
- removed KJSInherit enumeration constants as suggested by David Faure
- tested import of legacy keys JavaDomainSettings & ECMADomainSettings

Created attachment 586 [details]
forth patch, khtml side only

This is the final incarnation of the per-domain settings patch as it was
checked into the KDE CVS. No more khtml-side per-domain settings patches will
be posted to this bug anymore.

Created attachment 593 [details]
first patch, kcontrol side

This is the first preliminary patch for the per-domain configuration gui. I
intend to swap out the whole settings to an own widget class lateron but before
doing that I'm providing this patch as a request for comments.

I'm especially concerned about the tooltip texts so I'd like to have some
feedback - favourably by native English speakers.

Created attachment 621 [details]
second patch, kcontrol side

This patch adds full support for per-domain configurability of javascript and
java policies. It has also been tested with old keys (ECMADomainSettings and
JavaDomainSettings are correctly imported).

To achieve that I had to do some invasive refactoring in
kdebase/kcontrol/konqhtml. Firstly I added jspolicies.{h,cpp} and
policies.{h,cpp}, secondly I patched the PolicyDialog class not to hardcode
Java and JavaScript settings but to be much more generic. Last but not least I
added per-domain policy support to jsopts.{h,cpp} as well as javaopts.{h,cpp}
(reading, editing, writing).

Some more detailed explanations:

policies.{h,cpp}:
Contains a new generic class for policies, called Policies.
It contains only one policy, featureEnabled, as this is the least common
denominator for Java, JavaScript and Plugins and infrastructure methods for
loading, saving, defaults etc.

jspolicies.{h,cpp}:
Contains JSPolicies, derived from policies, adding JavaScript policies for
window.open and the like.

Also contains a widget JSPoliciesFrame for configuring those policies. This
widget is reused in jsopts.* and policydlg.*.

policydlg.{h,cpp}:
I totally removed the specialization on JavaScript and Java and replaced it
with a more generic system. It still provides the input of a domain as well as
the specification of the featureEnabled policy (which is now "java enabled"
resp. "javascript enabled"). Additionally the PolicyDialog instance can be
enhanced by a custom widget for configuration of further domain-specific
policies (which is done in jsopts).


To remain compatible I have to change the RFE in the following point:
The list of domains is not saved under the key "DomainSettings" but under
separate keys "JavaDomains" for java, "ECMADomains" for javascript and -- soon
to come -- "PluginDomains" for plugins.
This change also requires changes to the khtml_settings.cpp configuration
loading methods which I am going to tackle soon.

Still missing:
I did not touch plugins.{h,cpp} yet as it even misses a domain listview.

I also plan to merge the many copies of the domain listview (in java settings
and javascript settings) in a generic class as I have done with policydlg.

Factorization and plugins module are implemented/updated and working. 
 
Resolving now as everything works as expected. 
 
Simply reopen this bug if you detect issues.