Closed Bug 51820 Opened 25 years ago Closed 25 years ago

Would like ability to turn off all background images via a pref

Categories

(Core :: Layout, enhancement, P3)

Product:
Core
Component:
Layout
Platform:
All
Windows NT
Type:
enhancement

Tracking

()

Status:
VERIFIED DUPLICATE of bug 19260
Milestone:
Future

People

(Reporter: selmer, Assigned: attinasi)

Details

(Keywords: helpwanted)

Here is the request for a new pref from a user of our product: I'd like a checkbox: [ ] Disable background images Then, lines like: <BODY background="http://www.vvm.com/~action/images/AP_BackGround.jpg"> would be ignored if I checked that box! (This checkbox would be probably be ignored if "Automatically Load Images" is disabled.) Please please please!
prefs
Assignee: asa → dveditz
Component: Browser-General → Preferences: Backend
QA Contact: doronr → sairuh
Sure, there would need to be a pref. However, shouldn't this go to whoever would implement the feature first?
Um, sorry: Prefs backend is about the prefs mechanism in general. Specific prefs belong to whoever would implement the feature. I'm going to guess layout, but that's strictly a guess
Assignee: dveditz → clayton
Component: Preferences: Backend → Layout
QA Contact: sairuh → petersen
this sounds pretty similar to the image blocking feature in mozilla (which is turned off via a hidden pref for commercial bits). cc'ing morse since he works on that (ie, the image blocking stuff), to see if he'd have any thoughts here. yeah, this would be nifty!
Keywords: helpwanted
Yeah, this'd be cool. dbaron: do you have any idea where I might want to start looking to disable background images from loading? Would it be as simple as finding where the background attribute is parsed and ignoring it depending on a boolean pref? any guidance would be appreciated, thanks.
Background images can be disabled already by adding a single line to the user stylesheet: * { background-image: none ! important } However, we need a UI for this, and we need a way for editing the user stylesheet from that UI. What may be an idea is having a third user stylesheet, which has a special syntax which we can easily parse without having to deal with CSS' syntax directly. This solves the problem of having to deal with additions -- we just refuse them. Something like: /* prefs.css - this file is generated automatically. */ /* Do not edit! */ /* background pref */ * { background-image: none ! important } /* link color pref */ :link { color: blue; } :visited { color: purple; } Then the prefs stuff would just parse it by reading each line and comparing the bit from "/*" to "*/" with some internal prefs list, and then treating the rest as a magic string which matches certain things -- for example, the link colours pref above would be composed of ":link { color:" followed by a colour, then "; } :visited { color:" followed by a second colour, and then "; }". Maybe this is just too hacky and tacky, and we should go for a fully fledged UI for editing stylesheets.
Or maybe we could have plain old prefs and dynamically create/modify user stylesheets on startup using the CSSOM.
<triaging Clayon's list> Assigning to Preferences since this is a request for a new preference. When we choose to do this there will be some backend work needed to either create a rule in the user.css or to check the pref and 1) create a stylesheet for it (as D. Baron suggested), or 2) conditionalize the CSSRendering code (PaintBackground). Either way, contact me for that part. First the UI for the pref needs to be considered and possibly implemented.
Assignee: clayton → matt
Component: Layout → Preferences
QA Contact: petersen → sairuh
This isn't Preferences, and Matt certainly isn't going to implemenet this feature. The Preferences component is for problems with the preferences window itself, or with saving preferences in general (not specific ones). The backend work for this needs to be done first, before the UI (which would likely just consist of a single checkbox). back to layout
Assignee: matt → clayton
Component: Preferences → Layout
QA Contact: sairuh → petersen
I'm sorry that I sent it to the wrong component. I don't agree that the backend work should be done first. The decision on whether or not to do it at all needs to come first, then the UI design (maybe a simple checkbox) and then the actual implementation of it (the backend work), with the last two potentially in parallel since it is so small. I'l keep it for now. Once NS6 is out we can revisit who should make the call on this, since I have no clue who makes these decisions. CC'ing ekrock since he probably knows.
Assignee: clayton → attinasi
Summary: Would like ability to turn off all background images → Would like ability to turn off all background images via a pref
Target Milestone: --- → Future
No problem. I still think the UI should come last. This is how we do most of our prefs -- make the pref a manually settable option (in prefs.js), and add the UI later if it warrants one. But I'm done spamming...
Marc, implementing in parallel is fine, but as a general rule we don't implement UI for things that don't work. Usually, once the actual feature is available and tested, the UI gets created. You can test the backend by manually setting the pref in your prefs.js.
Accepting bug. I think the best way to do this is to do as D. Baron suggested and 'install' a rule like the one Ian H. suggested via the CSSOM. If we do decide to implement it this way then there is no 'backend' work to do, it is all script and can be done right in the front end (I think - my concept of front end / back end may be skewed).
Status: NEW → ASSIGNED
marc, wouldn't this be a dup of bug 19260? that one has been minused, in any case...
Thanks, Sarah - good catch. Marking as a dup of 19260. BTW: since we now have a preferences style sheet this should be pretty easy on the backend... see bug 40340 *** This bug has been marked as a duplicate of 19260 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
vrfy dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.