safe mode should disable userContent.css and userChrome.css

RESOLVED FIXED in mozilla1.9.2a1



13 years ago
7 years ago


(Reporter: darin.moz, Assigned: Natch)


(Blocks 1 bug, {user-doc-needed})

Bug Flags:
blocking1.9.2 -
blocking1.9.1 -
in-testsuite -
in-litmus ?

Firefox Tracking Flags

(Not tracked)



(1 attachment)



13 years ago
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

Comment 2

13 years ago
*** Bug 349661 has been marked as a duplicate of this bug. ***


11 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup


11 years ago
Flags: blocking1.9.1?
At bail out early if nsIXULAppInfo says we are in safe mode probably.

Comment 4

11 years ago
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-

Comment 5

10 years ago
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

Comment 6

10 years ago
Posted 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 7

10 years ago
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.
Comment on attachment 377953 [details] [diff] [review]
Like so?

Yeah, this looks fine.
Attachment #377953 - Flags: superreview?(bzbarsky) → superreview+


10 years ago
Flags: blocking1.9.2? → blocking1.9.2-

Comment 10

10 years ago
thanks, y'all!
Keywords: checkin-needed

Comment 11

10 years ago
Can someone check this in for me? Should still apply (I have it applied locally on tip as of yesterday).
Assignee: benjamin → highmind63
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1

Comment 13

10 years ago
Worth a user/dev doc? Can't really be tested afaik, litmus test would be nice.
Flags: in-testsuite-
Flags: in-litmus?


8 years ago
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.