Implement Gecko preference listener

RESOLVED WORKSFORME

Status

Camino Graveyard
Preferences
RESOLVED WORKSFORME
11 years ago
9 years ago

People

(Reporter: froodian (Ian Leue), Unassigned)

Tracking

Details

(Reporter)

Description

11 years ago
Certain preferences (adblocking, flashblock) rely on notifications from the preference pane to load and unload their associated stylesheets.  What this means is that these prefs can only be changed via the pref panes - changing them from about:config does nothing.  We should implement a pref listener for Gecko prefs so that we can fire off notifications when their values change.  STR:

1. Make sure adblocking is enabled
2. Visit a site with ads (http://nytimes.com)
3. go to about:config, change camino.enable_ad_blocking to false
4. Reload

What happens: Still no ads
What should happen: Should have ads
This is even "worse" on the trunk, where stylesheet load/unload doesn't require a page reload.

The use-case here doesn't make much sense, though; is there a more compelling underlying reason?

Comment 2

11 years ago
Other than about:config parity, you mean? That seems like a fairly compelling reason on its own. If we're going to have about:config at all, we should at least not cripple it any worse than it already is :-p

Comment 3

10 years ago
See also bug 411189, which is semi-related.

Comment 4

9 years ago
Having a Gecko prefs listener would help a lot with bug 384689. Without it, I'm not sure how to fix that bug outside of doing a pref lookup every time we start an autocomplete session, which sounds expensive.

Updated

9 years ago
Hardware: Macintosh → All

Comment 5

9 years ago
What specifically is this bug about that [PreferenceManager -addObserver:forPref:] doesn't provide?

Comment 6

9 years ago
(In reply to comment #5)
> What specifically is this bug about that [PreferenceManager
> -addObserver:forPref:] doesn't provide?

As far as I can tell from actually using that method in a real-world fix (see the other bug), nothing.

Unless Ian has a compelling reason to keep this open, I think we should just close it WORKSFORME, since we do indeed have an observer system we can use.

Comment 7

9 years ago
Resolving WORKSFORME per comment 5 et seq.

I've filed the Flashblock and ad-blocking problems as bug 458307 and bug 458304, respectively.

If there are other prefs where we have problems like this, we should file each as a separate bug, but I can't think of any more at the moment.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.