69786 - RFE: Need to have 'pref://' URLs to get values for preferences

Status: VERIFIED WONTFIX

(Core :: Preferences: Backend, enhancement, P4)

Description

[Marc Attinasi]

Daniel; Glazman had the idea of using URLs to get preference vlaues, so they can 
be used from CSS e.g. (color: url(pref://link.color);}

This could be used in many other situations too, where a pref is needed from 
script or CSS.

Comment 1

[timeless]

can networking help us?

Comment 2

[Marc Attinasi]

Yea, this is probably a networking bug, isn't it? I'd be very interested to knwo
how we get new schemes implemented - does anybody know?

Comment 3

[Doug Turner (:dougt)]

There are plenty of examples of how to do this (take a look at the about: 
protocol, or even datetime:).  The necko team doesn't have time to do this.  

Maybe the pref' owner can think about doing this. 

Comment 4

[Daniel Veditz [:dveditz]]

Making prefs visible this way would have serious security implications.

Signed scripts can already get prefs, via navigater.preference(), and chrome 
scripts get them via the nsIPref service.

Comment 5

[Doug Turner (:dougt)]

what serious security implications?  This would be a local URL, not accessible 
from the web.

Comment 6

[Gagan]

IMO pref:// isn't quite a different protocol and has little semantic equivalence
with the remaining schemes set. What would a pref:// mean on the location bar?
Plus would you really like to make your CSS not be standards compliant anymore?
How would this work in the rest of the world (which has no clue about pref://)?
I'd let some CSS gurus jump in here for clarifications but IMO adding pref as a
new scheme is a bad idea.

Comment 7

[Marc Attinasi]

> What would a pref:// mean on the location bar?

I presume that pref:///browsers.link_color in the location bar would return the
value of that pref in a mini-document, just like about:mozilla displays
improtant philosophical perspectives on Mozilla in a mini-document.

> Plus would you really like to make your CSS not be standards compliant anymore?

This would not change our standards copliance in any way. We supports lots of
nonstandard stuff in our CSS, mostly for the benefit of the UI. CSS itself
allows for extensions by providing specific rules for handling parsing errors:
so, provided that we decide to support something non-standard, a declaration
like 'color : -moz-url(pref:///browser.link_color)' is fine, as all other
browsers must ignore the declaration silently (just like they ignore -moz-radius
and many other propietary properties and values now).

> How would this work in the rest of the world

I don't think that the rest of the world would have much use for the
pref-scheme, and correct me if I am wrong, but that is not dissimilar to the
chrome-scheme.

The advantage is that prefs could be accessed from CSS and script using an
existing mechanism, namely the URL - at least that was the driving idea behind
this. For example, if we want to use the user's preference for the link color in
CSS now, we have to use C++ code. This proposal initially came up as a potential
solution to that very problem.

Comment 8

[Alec Flett]

I have to agree, this is pretty cool, but I don't know if the code it would
replace would justify the effort (and bulk) of adding a new protocol...

Comment 9

[Alec Flett]

besides, I think there are better ways to do this.
for example, how about RDF templates in CSS?
i.e. you would use a RDF datasource & set of parameters to generate a list of
CSS rules, much like we currently use RDF to generate XUL.

then we could reflect prefs into RDF (I've been wanting to do THAT for a while,
for other reasons)

Comment 10

[Gagan]

I like alecf's idea. And would like to second that... anyone see problems with 
it? 

Comment 11

[Marc Attinasi]

Does that mean we would be coupling RDF and Style? I'm not sure that is a good
idea, specifically for situations where we want a small code footprint
(...laughing...). Aside from that concern, I am in no position to comment as I
know very little about RDF and how it is used in XUL - sorry.

For our immediate purposes in the style system we can just implement a value
like '-moz-linkcolor' that causes the StyleSystem to look at the pref value, but
I was looking for a slightly more general solution that might have uses outside
of link coloring. That said, the -moz-linkcolor idea is similar to the CSS3 UI
Color proposals currently under consideration. So, if we just want to solve the
link color problem, and the value of a pref scheme is not seen as high enough to
merit the effort, then I'd say we just WONTFIX this bug and move along.

(BTW: the link color pref bug is bug 58534)

Comment 12

[timeless]

i like Comments From Marc Attinasi 2001-02-22 14:02, but ...

being able to quickly check the value of a preference like this instead of 
having to find the correct prefs.js and then search for it (only to find out 
that the setting is not even there [perhaps it's in all.js or some other 
file...]) would be rather useful. 

Comment 13

[Hixie (not reading bugmail)]

If this is only for link colours/decoration, then we should use new colour 
keywords. What other issues are there?

Comment 14

[Hixie (not reading bugmail)]

(I should add an "IMHO" to that of course...)

Comment 15

[Daniel Veditz [:dveditz]]

timeless: there are better ways to easily check the value of prefs without 
inventing a new protocol. See the bug about implementing 4.x's about:config 
(with improvements).

Comment 16

[Tim Powell]

BTW, about:config is in bug 57969 and bug 37592.

Comment 17

[Marc Attinasi]

We can solve the link colors issue in other ways. This suggestion sounded good
to me because it a) solved an immediate problem and b) seemed to have lots of
potential value to other areas (e.g. chrome, signed scripts).

It seems that there is more push-back than support so I'm happy to drop the
request. However, I have not really seen any concrete reasons that this is a bad
idea except possibly a comment from Gagan: "IMO pref:// isn't quite a different
protocol and has little semantic equivalence with the remaining schemes set."
and alecf's comment that this is a lot of work for the benefit (Comments From
Alec Flett 2001-02-22 15:22).

Comment 18

[Daniel Veditz [:dveditz]]

I think Brian owns prefs now. I know I don't

Comment 19

[Daniel Wang]

about:config just works better
-> wfm

Comment 20

[Tim Powell]

The pref URLs are intended for a different purpose than about:config. Based on 
the discussion in this bug, I could see closing this as WONTFIX, but not 
WORKSFORME.

Comment 21

[Alec Flett]

I'm prefs owner now and I can definitely say this is a WONTFIX

Comment 22

[Alec Flett]

and now marking as such.

Comment 23

[sairuh (rarely reading bugmail)]

yep, v.