Closed Bug 396610 Opened 17 years ago Closed 17 years ago

it's no longer possible to disable user configuration of handlers

Categories

(Firefox :: File Handling, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3 beta1

People

(Reporter: myk, Assigned: myk)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

The new Applications prefpane disregards the value of pref.downloads.disable_button.edit_actions, so it's no longer possible to disable user configuration of handlers.  But mkaply says this is useful for enterprise users and should remain possible.

To fix this, we'll need to disable (or prevent from appearing) the actions dropdown menu when the user selects a type and the pref is set to true.
This patch disables the list of types when the aforementioned preference is set to true and reenables it when the pref is set to false.  When disabled, browsing the list still works, including scrolling through it, sorting it, and searching through it with the filter field, but it isn't possible to select an item in the list and choose an action for it.
Attachment #281394 - Flags: review?(gavin.sharp)
Attached patch patch v2: unhorked (obsolete) — Splinter Review
Attachment #281394 - Attachment is obsolete: true
Attachment #281754 - Flags: review?(gavin.sharp)
Attachment #281394 - Flags: review?(gavin.sharp)
Requesting wanted-1.9 for this Applications prefpane polish fix.
Flags: blocking-firefox3?
Comment on attachment 281754 [details] [diff] [review]
patch v2: unhorked

This isn't quite right. Although it does disable the pane correctly when the pref is set to false, it fails to disable the pane when the pref value is locked, because the <preference> element's valueFromPreferences method calls getBoolPref, which throws when the pref is locked. Supporting this pref without supporting it being locked is somewhat pointless, since it's easy for users to modify prefs using about:config.

(See bug 352032 for an example of a config that can be used to lock prefs. As a side note, it turns out that because of that bug that we shipped Firefox 2 without support for this pref.)
Attachment #281754 - Flags: review?(gavin.sharp) → review-
You can probably let the preference bindings do this by setting the "preference" attribute on the richlistbox (see the "paneload" handler and setElementValue in preferences.xml).
(In reply to comment #4)
> This isn't quite right. Although it does disable the pane correctly when the
> pref is set to false, it fails to disable the pane when the pref value is
> locked, because the <preference> element's valueFromPreferences method calls
> getBoolPref, which throws when the pref is locked. Supporting this pref 
> without supporting it being locked is somewhat pointless, since it's easy for
> users to modify prefs using about:config.

Hmm, ok, then I misunderstood the behavior of the pref.  I thought its value determined whether or not the UI is enabled, but a look at the code clarifies that the values of such prefs are irrelevant, and it's their lock statuses that determine whether or not their UI is enabled.


> (See bug 352032 for an example of a config that can be used to lock prefs. As
> a side note, it turns out that because of that bug that we shipped Firefox 2
> without support for this pref.)

Hmm, in that case it's not a regression from bug 377784, so removing this from the list of blockers for that bug.


(In reply to comment #5)
> You can probably let the preference bindings do this by setting the
> "preference" attribute on the richlistbox (see the "paneload" handler and
> setElementValue in preferences.xml).

Thanks for the tip.  I'll give that a try.
No longer depends on: 377784
(In reply to comment #6)
> > (See bug 352032 for an example of a config that can be used to lock prefs. As
> > a side note, it turns out that because of that bug that we shipped Firefox 2
> > without support for this pref.)
> 
> Hmm, in that case it's not a regression from bug 377784, so removing this from
> the list of blockers for that bug.

Err, since bug 352032 fixed the functionality on the trunk, this really is a regression from bug 377784, so adding it back as a blocker on that bug.  Sorry about the churn.
Blocks: 377784
Here's a version of the patch that disables the prefpane when the relevant preference is locked.  I used the config file Phil Ringnalda attached in bug 352032, comment 2 to test this.

Note: I also investigated using CSS to disable the selection when the richlistbox is disabled, but while it's easy to use CSS to turn off the XBL that adds the dropdown menu to a selected richlistitem, it's harder to use CSS to disable the select styling entirely, so I decided it would be better to simply not select the last selected item if the richlistbox is disabled, as with the previous patch.
Attachment #281754 - Attachment is obsolete: true
Attachment #282595 - Flags: review?(gavin.sharp)
Attachment #282595 - Flags: review?(gavin.sharp) → review+
Comment on attachment 282595 [details] [diff] [review]
patch v3: works with locked pref

Requesting approval for this low-risk regression fix that makes it possible for enterprises to once again disable content handling configuration.
Attachment #282595 - Flags: approval1.9?
Attachment #282595 - Flags: approval1.9? → approval1.9+
Checking in browser/components/preferences/applications.js;
/cvsroot/mozilla/browser/components/preferences/applications.js,v  <--  applications.js
new revision: 1.13; previous revision: 1.12
done
Checking in browser/components/preferences/applications.xul;
/cvsroot/mozilla/browser/components/preferences/applications.xul,v  <--  applications.xul
new revision: 1.5; previous revision: 1.4
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: