Version: (using KDE Devel) Installed from: Compiled sources Title says it all. See discussion: http://lists.kde.org/?t=103428224900008&r=1&w=2 Summarizing what has been said so far followed by the adapted rfc (having now become an rfe): - tabs stay separate for java/javascript/plugins ui-wise - having all global java/js/plugins under [Java/JavaScript Settings] unprefixed - having per-domain settings under [domain] where domain is the domain name or some ip address (either ipv4 or ipv6, shouldn't matter) - per-domain js settings are prefixed with "javascript." - make bool isWindowBlaEnabled(...) be enum BlaPolicy windowBlaPolicy(...) [...] > > RFC: Access Control over JavaScript Properties Globally and Per-Domain > > 1. Overview > > Currently Java, JavaScript and Plugins are handled on separate tabs though > their configuration data is saved under the common key [Java/JavaScript > Settings]. Ui-wise that should stay that way, meaning that the per-domain > settings for Java, JavaScript and Plugins (when finally implemented but > outside if this proposal) are totally separated. > > Config-wise the per-domain settings for Java and JavaScript are also saved > under separate keys, with options separated with colons. > > We leave the Java and Plugins setting as is, they are not part of this > proposal. > > The properties whose access is to be controlled are: > Property Access Possible options & additional information > window.open invocation Allow/Ask/Deny/Smart, already implemented globally > window.moveBy invocation Allow/Ignore > window.moveTo invocation Allow/Ignore > window.resizeBy invocation Allow/Ignore > window.resizeTo invocation Allow/Ignore > window.focus invocation Allow/Ignore > window.defaultStatus setter Allow/Ignore > window.status setter Allow/Ignore > > 2. New Configuration Keys > > To save those settings globally, I propose the following additions to > [Java/JavaScript Settings]: > WindowOpenPolicy as is WindowMovePolicy: 0 allow (default), 1 ignore WindowResizePolicy: 0 allow (default), 1 ignore WindowFocusPolicy: 0 allow (default), 1 ignore WindowStatusPolicy: 0 allow (default), 1 ignore > > For the per-domain settings the ECMADomainSettings key should be scrapped and replaced with dedicated per-domain config keys which contain the same option with the same values as above except that they are prefixed by "javascript.". Not having a corresponding javascript.WindowBlaPolicy options means to inherit the global one. > > Example: [foo.bar.com] javascript.EnableJavaScript=true javascript.WindowOpenPolicy=0 javascript.WindowMovePolicy=1 javascript.WindowResizePolicy=1 > > would set the policies for foo.bar.com to accept javascript, to allow > popups, ignore window move and resize attempts as well as inherit the > global behaviour for focus stealing and status text changes. > The advantages of doing this are: 1.) No special parsing code needed. Use KConfig to obtain the settings. Your code will only have to check if a specific host name entry exists and use the settings there. If there is no entry for a specific property under the group or there is no domain specific entry at all, use the global/default setting. 2.) No position dependency. One does not have to worry about where a speicifc entry belongs which makes it much easier to read and hence administer manually. 3.) Can easily be converted/manipulated into a new format without loosing the user's settings in the future using kconf_update tool. 4.) Easier to extend than the other format because properties can be added without having to worry about positions etc... (bluntly copied from Dawit's mail without permission ;-) ) > > 3. GUI Representation > > The JavaScript Web Popups Policy section of the JavaScript tab should be > adapted to: > > --- JavaScript Policies --- > Web Popups: (*) allow ( ) ask ( ) deny ( ) smart > Move Windows: (*) allow ( ) ignore > Resize Windows: (*) allow ( ) ignore > Bring Windows to Foreground: (*) allow ( ) ignore > Change Status Bar Text: (*) allow ( ) ignore > > The configuration defaults are checked. > > The per-domain settings screen becomes: > > Host or domain name: [______________] > JavaScript Policy: [Use global/Allow/Reject] > Web Popups: (*) use global ( ) allow ( ) ask ( ) deny ( ) smart > Move Windows: (*) use global ( ) allow ( ) ignore > Resize Windows: (*) use global ( ) allow ( ) ignore > Bring Windows to Foreground: (*) use global ( ) allow ( ) ignore > Change Status Bar Text: (*) use global ( ) allow ( ) ignore > > The per-domain defaults are checked. > If JavaScript Policy is set to deny, the succeeding options could be grayed > out, otherwise they should stay available, even if the global JavaScript > Policy setting is set to off. > > 4. API Concerns > > The WindowOpenPolicy setting is actually not integrated into the > khtml_settings class. I do not know the specific cause for this, but for > per-domain management I propose that all the settings mentioned under 2. > are integrated into khtml_settings. > > The new preliminary API might look like: > // Java and JavaScript > bool isJavaEnabled( const QString& hostname = QString::null ); > bool isJavaScriptEnabled( const QString& hostname = QString::null ); > bool isJavaScriptDebugEnabled( const QString& hostname = QString::null); > bool isPluginsEnabled( const QString& hostname = QString::null ); > + int windowOpenPolicy( const QString& hostname = QString::null ); + enum MovePolicy windowMovePolicy( const QString& hostname = QString::null ); + enum ResizePolicy windowResizePolicy( const QString& hostname = QString::null ); + enum FocusPolicy windowFocusPolicy( const QString& hostname = QString::null ); + enum StatusPolicy windowStatusPolicy( const QString& hostname = QString::null ); > [...] dependent bugs this bug would solve: bug #21709
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.