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)
Firefox
File Handling
Tracking
()
RESOLVED
FIXED
Firefox 3 beta1
People
(Reporter: myk, Assigned: myk)
References
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
6.20 KB,
patch
|
Gavin
:
review+
mconnor
:
approval1.9+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•17 years ago
|
||
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)
Assignee | ||
Comment 2•17 years ago
|
||
Attachment #281394 -
Attachment is obsolete: true
Attachment #281754 -
Flags: review?(gavin.sharp)
Attachment #281394 -
Flags: review?(gavin.sharp)
Assignee | ||
Comment 3•17 years ago
|
||
Requesting wanted-1.9 for this Applications prefpane polish fix.
Flags: blocking-firefox3?
Comment 4•17 years ago
|
||
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-
Comment 5•17 years ago
|
||
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).
Assignee | ||
Comment 6•17 years ago
|
||
(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
Assignee | ||
Comment 7•17 years ago
|
||
(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
Assignee | ||
Comment 8•17 years ago
|
||
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)
Updated•17 years ago
|
Attachment #282595 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 9•17 years ago
|
||
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?
Updated•17 years ago
|
Attachment #282595 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 10•17 years ago
|
||
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
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
You need to log in
before you can comment on or make changes to this bug.
Description
•