Add some new prefs to the about:support whitelist

VERIFIED FIXED in mozilla12

Status

()

defect
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: davemgarrett, Assigned: aceman)

Tracking

(Blocks 1 bug)

Trunk
mozilla12
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
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
status1.9.2: --- → ?
status2.0: --- → ?
Blocks: 630021
Hi. I could patch this. Who can decide which of these prefs can go in?
Assignee: nobody → acelists
Ping

(In reply to :aceman from comment #2)
> Hi. I could patch this. Who can decide which of these prefs can go in?
The ones from comment 0 make sense to me, modulo comment 1.
(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.
> 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
(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: ? → ---
status2.0: ? → ---
(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?
(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.
Posted patch patchSplinter Review
Attachment #585840 - Flags: review?(dtownsend)
Mark Banner, do you want the same change for Thunderbird? Maybe it does not make much sense, just for consistency.
(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.
Attachment #585840 - Flags: review?(dtownsend) → review+
Posted patch patch for TBSplinter Review
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 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+
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]
Checked both patches in:

https://hg.mozilla.org/mozilla-central/rev/771fbd0b8718
http://hg.mozilla.org/comm-central/rev/bec2f20e8669
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [checkin of both patches needed]
Target Milestone: --- → mozilla12
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.