295827 - Camino ad blocking preference removes userContent.css file when deactivating

Status: VERIFIED FIXED

(Camino Graveyard :: Preferences, defect)

Description

[Samuel Sidler (old account; do not CC)]

As mentioned in bug 295755, when deactivating Camino's new ad blocking
preference, the userContent.css file is completely deleted. This is bad as it
doesn't allow users to keep any other preferences they may have set in the file.

One thing we could do is put special commented lines in the file around our ad
blocking code and only delete that information when deactivating ad blocking.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

It would probably be better to just use an @import to import the ad blocking
file, and remove the import when disabled, if you still want to use userContent.css.

However, it was suggested that using
http://lxr.mozilla.org/mozilla/source/layout/base/nsIStyleSheetService.idl would
be a better way to implement this, without having to rely on userContent hackery.

Comment 2

[Wevah (Nate Weaver)]

I agree that simply using userContent.css like this is a Bad Idea.

Comment 3

[Mike Pinkerton (not reading bugmail)]

lots of work for something 0.1% of users understand.

Comment 4

[Ben]

(In reply to comment #3)
> lots of work for something 0.1% of users understand.

Yeah... thing is, I already had my own copy of that css linked into my
userContent.css file, as well as some other stuff that's fairly important to my
browsing style... of course, I could add removing that checkbox from the prefs
to my list of standard things to do when I'm installing a new build of Camino,
but that seems like something I shouldn't have to do.  Besides that, I don't
know how you all are currently storing the css that blocks ads, but it might
make some sense to just put in a file someplace which camino can move (or copy)
to the appropriate location, and then use and @import rule on.  (or you could do
the thing suggested in comment #1)

Also, if you do decide to use an @import rule, there would be a couple
additional things that would be good to do.
1.  put a comment at the top of your adblock css file that says the browser
edits it, so users shouldn't. users should use userContent.css
2.  have a list of a couple of possible names for the file and check whether or
not they exist before moving the file... so like if I already have a file called
adBlock.css, you shouldn't overwrite that with yours.  have a list of, say, 3
filenames to try, and if all of them are taken, then complain that you can't
turn on ad blocking because the user is already using all of the possible
filenames...

Comment 5

[Mike Pinkerton (not reading bugmail)]

i tried using @import and couldn't get it to work at all. anyone else have any luck?

Comment 6

[Jasper]

Just to update, adding -> @import url(blockfile.css); to userContent.css and
making sure the blockfile.css is in the profile chrome folder works fine, I tested.

Comment 7

[Philip Chee]

We (Flashblock) use @import in userContent.css. I found that @import directives
have to be at the top of the userContent.css file

Comment 8

[Wevah (Nate Weaver)]

(In reply to comment #7)
> We (Flashblock) use @import in userContent.css. I found that @import directives
> have to be at the top of the userContent.css file

Aye, that's part of the W3C recommendation, even.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This was fixed by the fix for bug 305010.