Closed Bug 333808 Opened 15 years ago Closed 11 years ago

safe mode should disable userContent.css and userChrome.css

Categories

(Toolkit :: Startup and Profile System, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: darin.moz, Assigned: Natch)

References

(Blocks 1 open bug)

Details

(Keywords: user-doc-needed)

Attachments

(1 file)

Safe mode should disable userContent.css and userChrome.css

Some extensions will go and add rules to userContent.css (e.g., flash block), and then when uninstalled they will not bother removing those rules.  As a result, a user's profile can be left in a broken state, where in the case of flash block, many flash pages will fail to work properly.  The symptoms are complicated by the fact that some flash content will still work.

I think it might help people debugging problems like this if they safe mode would disable userContent.css.  It'd probably make sense to disable userChrome.css as well.
It may also make sense to have a safe mode option to restore the default set as is available for localstore.rdf
*** Bug 349661 has been marked as a duplicate of this bug. ***
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Flags: blocking1.9.1?
At http://mxr.mozilla.org/mozilla-central/source/layout/style/nsLayoutStylesheetCache.cpp#179 bail out early if nsIXULAppInfo says we are in safe mode probably.
Not going to block on this, but I'll take it since it's pretty trivial.
Assignee: nobody → benjamin
Flags: blocking1.9.1? → blocking1.9.1-
Since all the docs portray safe mode as a "safe place" where a user can assume that anything that goes wrong here must be a firefox issue *and* from a security POV this is supposed to be somewhat of a safe-haven (which user[Content|Chrome].css ensure is not true), perhaps this should block 1.9.2?
Flags: blocking1.9.2?
Version: unspecified → Trunk
Attached patch Like so?Splinter Review
Benjamin, I hope you don't mind me taking this, it is pretty simple indeed!
Attachment #377953 - Flags: review?(benjamin)
Comment on attachment 377953 [details] [diff] [review]
Like so?

I'm not a peer of this code, but this looks fine to me. Asking for sr from a proper owner.
Attachment #377953 - Flags: superreview?(jst)
Attachment #377953 - Flags: review?(benjamin)
Attachment #377953 - Flags: review+
Attachment #377953 - Flags: superreview?(jst) → superreview?(dbaron)
Comment on attachment 377953 [details] [diff] [review]
Like so?

I'm not really familiar with the stylesheet code either, but dbaron is.
Attachment #377953 - Flags: superreview?(dbaron) → superreview?(bzbarsky)
Comment on attachment 377953 [details] [diff] [review]
Like so?

Yeah, this looks fine.
Attachment #377953 - Flags: superreview?(bzbarsky) → superreview+
Flags: blocking1.9.2? → blocking1.9.2-
thanks, y'all!
Keywords: checkin-needed
Can someone check this in for me? Should still apply (I have it applied locally on tip as of yesterday).
http://hg.mozilla.org/mozilla-central/rev/4485b488ce96
Assignee: benjamin → highmind63
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Worth a user/dev doc? Can't really be tested afaik, litmus test would be nice.
Flags: in-testsuite-
Flags: in-litmus?
Flags: in-litmus? → in-litmus?(hskupin)
Keywords: user-doc-needed
(In reply to comment #13)
> Worth a user/dev doc? Can't really be tested afaik, litmus test would be nice.

If you are interested I can guide you through Mozmill. It sounds like a nice restart test.
Flags: in-litmus?(hskupin) → in-litmus?(andrei.domuta)
You need to log in before you can comment on or make changes to this bug.