395548 - Enhancement: support arbitrary keys in webapp.ini (simple patch to profile.js)

Status: RESOLVED WONTFIX

(Mozilla Labs :: Prism, enhancement)

Description

[Mukunda]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082908 Webrunner/0.6

I would like to suggest that the profile.js file be modified to allow for arbitrary profile keys to be used. I am adding features by way of an extension and I am forced to patch profile.js in order to add my own custom webapp.ini settings. The profile.js parser has a preset list of allowed parameter keys and no new ones can be accessed without modification to that file. I can submit a patch to make this change if it would be acceptable.

Reproducible: Always

Steps to Reproduce:
1. add a new key/value pair to webapp.ini
2. update the profile.webapp archive to include the updated webapp.ini
3. try to access the new profile.key chrome javascript

Actual Results:  
no extra webapp profile property is accessible. The profile.js parser ignores unknown keys.

Expected Results:  
Some easy way to access the new ini value from an extension.

I will submit a patch that fixes this issue, however, I'm not sure that my approach is the best one, feedback would be appreciated.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

I am interested in seeing some of the arbitary key/values. I am not sure this is the best approach, so uses cases are needed.

Comment 2

[Mukunda]

Attachment: my simple approach to support arbitrary webapp.ini configuration properties

This patch for profile.js will add a new storage namespace (a javascript object/hash named extra) within the profile object which will hold arbitrary webapp.ini keys. Any key that doesn't match the list of standard parameters will be stored as keys within the "extra" object.

Comment 3

[Mukunda]

my use case is to provide a way to configure the url sandboxing feature - so that I can supply a list of regex patterns that will match "internal" links while others are considered external and load in the default browser.  I'm sure there could be other use cases but this was my reason for wanting this feature.

Comment 4

[Matthew Gertner]

Well we're planning to add that as a standard feature anyway. Would suggest renaming this bug to reflect that unless other plausible use cases for arbitrary keys can be found.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

I'd like to close this as WONTFIX. Arbitrary keys in webapp.ini doesn't sound like a good plan. I'd rather have explicit features added as needed.