Closed
Bug 593443
Opened 14 years ago
Closed 13 years ago
Add some new prefs to the about:support whitelist
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
VERIFIED
FIXED
mozilla12
People
(Reporter: davemgarrett, Assigned: aceman)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
1.59 KB,
patch
|
mossop
:
review+
|
Details | Diff | Splinter Review |
1.58 KB,
patch
|
standard8
:
review+
|
Details | Diff | Splinter Review |
I would like to propose adding a handful of new preferences to the whitelist to allow any of their non-default settings to be listed in about:support. (not shown if still using default) Reasons are listed here but they don't need to be added with the entries in the file.
browser.cache. <-- bad settings break things (ex: addon installation)
html5. <-- support should know what parser is being used and how
image.mem. <-- new features that may have issues for some
media. <-- things like autoplay, its cache, and disabled formats
svg. <-- if it's off it should say so
webgl. <-- new features that may have issues for some
Most cover new prefs for new features. Most are bools or ints; the one string is webgl.osmesalib which is just a path.
GPU acceleration related prefs were already added in bug 590841.
Looks to be as simple as adding the prefixes to PREFS_WHITELIST in /toolkit/content/aboutSupport.js
No new strings needed.
Reporter | ||
Comment 1•14 years ago
|
||
1.9.2 could use a few of these too:
browser.cache.
media.
svg.
The old demo html5 parser was disabled for 1.9.2.9 so its pref wouldn't be helpful there anymore.
Product: Firefox → Toolkit
QA Contact: general → general
Reporter | ||
Updated•14 years ago
|
status1.9.2:
--- → ?
Reporter | ||
Updated•14 years ago
|
Blocks: about:support++
Hi. I could patch this. Who can decide which of these prefs can go in?
Assignee: nobody → acelists
Comment 3•13 years ago
|
||
Ping
(In reply to :aceman from comment #2)
> Hi. I could patch this. Who can decide which of these prefs can go in?
![]() |
||
Comment 4•13 years ago
|
||
Comment 5•13 years ago
|
||
(In reply to Dave Garrett from comment #0)
> browser.cache. <-- bad settings break things (ex: addon installation)
Sounds fine.
> html5. <-- support should know what parser is being used and how
Not useful anymore I think.
> image.mem. <-- new features that may have issues for some
Do we expect people to play with these much?
> media. <-- things like autoplay, its cache, and disabled formats
Seems fine
> svg. <-- if it's off it should say so
There seems only one thing under here, not sure how useful that is.
> webgl. <-- new features that may have issues for some
Seems fine.
![]() |
||
Comment 6•13 years ago
|
||
> Do we expect people to play with these much?
Sadly, yes.
Yes, image.mem. is very important for those complaining about high memory usage. The defaults for some of these prefs have even been changed between FF versions 4->9 so people experiment with them even before the official change.
Thanks for replying, I'll make the patch.
Status: NEW → ASSIGNED
Reporter | ||
Comment 8•13 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #5)
> (In reply to Dave Garrett from comment #0)
> > html5. <-- support should know what parser is being used and how
>
> Not useful anymore I think.
Yep, but someone added it elsewhere already anyway.
> > webgl. <-- new features that may have issues for some
>
> Seems fine.
As was this one.
status1.9.2:
? → ---
(In reply to Dave Garrett from comment #8)
> > > html5. <-- support should know what parser is being used and how
> > Not useful anymore I think.
> Yep, but someone added it elsewhere already anyway.
Should it be removed?
Reporter | ||
Comment 10•13 years ago
|
||
(In reply to :aceman from comment #9)
> (In reply to Dave Garrett from comment #8)
> > > > html5. <-- support should know what parser is being used and how
> > > Not useful anymore I think.
> > Yep, but someone added it elsewhere already anyway.
>
> Should it be removed?
I don't see any reason to. There's still a few prefs there that could be fiddled with (e.g. html5.offmainthread) even if the main reason I suggested it initially is now gone.
![]() |
Assignee | |
Comment 11•13 years ago
|
||
Attachment #585840 -
Flags: review?(dtownsend)
![]() |
Assignee | |
Comment 12•13 years ago
|
||
Mark Banner, do you want the same change for Thunderbird? Maybe it does not make much sense, just for consistency.
Comment 13•13 years ago
|
||
(In reply to :aceman from comment #12)
> Mark Banner, do you want the same change for Thunderbird? Maybe it does not
> make much sense, just for consistency.
I'd be fine with those being added.
Updated•13 years ago
|
Attachment #585840 -
Flags: review?(dtownsend) → review+
![]() |
Assignee | |
Comment 14•13 years ago
|
||
Version for Thunderbird, synchronizing all prefs with current FF version.
Attachment #586191 -
Flags: review?(mbanner)
Keywords: checkin-needed
Whiteboard: [after checkin of patch for FF, leave the bug open for TB patch]
Comment 15•13 years ago
|
||
Comment on attachment 586191 [details] [diff] [review]
patch for TB
Normally we prefer to separate patches like this onto Thunderbird (or mailnews core) specific bugs, but I'll take it this time.
Attachment #586191 -
Flags: review?(mbanner) → review+
![]() |
Assignee | |
Comment 16•13 years ago
|
||
Thanks, I can do separate it next time, if possible. But some patches, like bug 559500 must be merged simultaneously.
Whiteboard: [after checkin of patch for FF, leave the bug open for TB patch] → [checkin of both patches needed]
Comment 17•13 years ago
|
||
Checked both patches in:
https://hg.mozilla.org/mozilla-central/rev/771fbd0b8718
http://hg.mozilla.org/comm-central/rev/bec2f20e8669
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [checkin of both patches needed]
Target Milestone: --- → mozilla12
You need to log in
before you can comment on or make changes to this bug.
Description
•