468377 - Compenents Using Preferences Should Also Use a Preference Observer

Status: RESOLVED WONTFIX

(Core :: General, enhancement)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13

I ususally have browser.xul.error_pages.enabled set False because I prefer to have an error popup instead of an error page.  Recently, I wanted to examine the error page.  I found that using about:config to set browser.xul.error_pages.enabled as True did not take effect unless I terminate and then relaunched SeaMonkey.  

It appears that changes to at least some preference variables do not become effective immediately.  Instead, they must first be written to prefs.js and then read back from prefs.js.  This requires terminating and restarting.  

Reproducible: Always

Steps to Reproduce:
1.  Attempt to view the cited URL, which is for a non-existent domain.  
2.  Request about:config, enter browser.xul in the Filter input area, and double-click on browser.xul.error_pages.enabled to change its setting.  
3.  Again, attempt to view the cited URL. 
4.  Terminate browser.  
5.  Again, attempt to view the cited URL. 


Actual Results:  
In step #1, either an error page or an error popup will appear, depending on the current setting of browser.xul.error_pages.enabled.  

In step #3, the result will be the same as in step #1.  It appears as if the preference was not changed.  

In step #5, the change is finally seen to be effective.  Whatever response was obtained in step #1, the opposite response is now seen.  

Expected Results:  
In step #3, the change should seen to be effective.  Whatever response was obtained in step #1, the opposite response should be seen.  That is, the result of step #3 should be the same as the result of step #5.  

The "Steps to Reproduce" require either that browser.xul.error_pages.enabled not be set in user.js or that the statement in user.js be commented out.  

I think this is a regression because I don't recall ever having to terminate my browser after using about:config.  However, I don't often change preferences via about:config; so I can't remember when this last worked correctly (if ever).

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> It appears that changes to at least some preference variables do not become
> effective immediately.  Instead, they must first be written to prefs.js and
> then read back from prefs.js.  This requires terminating and restarting.

That has always been the case. It depends on whether the code reading the preference uses a preference observer to react to changes immediately.

If you think a given preference should be made "live", feel free to file a new bug or morph this one to cover it specifically, but this bug's summary doesn't reflect an resolvable issue unless you're proposing a reworking of the entire pref system.

Comment 2

[David E. Ross]

Inconsistent responses by different components to changed preferences should not be acceptable design.  Users have no way to know which components will recognize a change immediately and which will not.  Thus, this should be consistent throughout all Mozilla applications.  

I can understand when a changed preference does not result in a change to a page that has already been rendered.  When a changed preference will only affect some future action, however, it should indeed be effective without the need to terminate the application and relaunch it.  

Just think of a user in the middle of doing financial transactions a bank's Web site.  The user decides that a change in a preference is needed.  Under the current situation, he may have to log out, terminate the browser, relaunch the browser, login again at the bank's site, recreate transactions that were left incomplete, and then continue with the session.  Is this how users are respected by the design of Gecko?  

I have reopened this bug report, changed the Summary and Component, and marked it as an RFE.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Not all preferences need to be live, and forcing them all to be would be needless overhead. It seems like you've identified one that probably should be, and are using it as the basis to request re-architecture of the entire preferences system, or a new wide-ranging policy change. That's not going to happen.

> Just think of a user in the middle of doing financial transactions a bank's Web
> site.  The user decides that a change in a preference is needed.  Under the
> current situation, he may have to log out, terminate the browser, relaunch the
> browser, login again at the bank's site, recreate transactions that were left
> incomplete, and then continue with the session.  Is this how users are
> respected by the design of Gecko?  

Users who care to change obscure hidden preferences using about:config? Yes, quite frankly. I doubt you would get much opposition to making browser.xul.error_pages.enabled live, so perhaps you should focus on that. I hope you're aware that the fact that you see a need to change it at all makes you part of a pretty small minority of users, though.