Closed Bug 384778 Opened 12 years ago Closed 8 years ago
Allow replacing blocked images instead of blocking them
This continues a discussion started in bug 337246 comment 3. Right now Gecko has a very useful undocumented feature (or a bug, whatever you call it). By changing uri.spec (an ugly hack) a content policy can not only block an image but also replace the image by something else. This is useful to display replacement images ("blocked by Foo" or something like AddArt extension). Because of bug 337246 the hack no longer works. As far as I know nobody is really relying on this feature and this is certainly no priority, but for Adblock Plus (and probably a number of other extensions) it would be nice to have this - if documented and reliable. So if some proper way to do this could be added at low cost, I think it should be done. Questions to consider: what would be the proper way to implement this? What should happen to security checks (called before content policies, after them, or twice)?
Hmm. Good question about security checks. We want security checks before content policies, because we don't want to put up UI information on unblocking stuff that wouldn't load anyway, I think. We don't want security checks twice -- they're expensive. And forcing all backend content policy callers to duplicate security check code is odd. To me, this suggests that content policies should do their own security checks if they rewrite the URI, and thus be given the nsIPrincipal in question. Which I think they should get anyway, no matter what we decide here. As for how to expose this... I'm not sure what a good API is.
I'd like to second my interest in officially incorporating this feature. I created http://rickrolldb.com which generates a user-vetted AdBlockPlus subscription list of rickrolls. Unfortunately we're often forced to block the entire page body and so people just see a blank page (still better than Never Gonna Give You Up though). Ideally we'd be able to display a small notice to the user that they'd been protected, do you disagree with this submission, etc. but it sounds like Firefox3's "bugfix" will prevent this from ever being realized!
Note that if you really wanted to do this, you could use an XBL binding (similar to the pluginfinder binding) to do it...
I'm one of the people Wladimir mentioned behind Add-Art. And yes, this feature is pretty critical to our work. From our understanding, this feature is the simplest solution. Although if there is another way we're missing using XBL, please contact us here: http://dev.eyebeam.org/projects/add-art/wiki/Mailing%20List or me personally here: http://visitsteve.com/contact/ While I imagine our projects may seem small and on the fringes, they help add to the "fully customizable" part of firefox and improving the browsing experience, which is why we all love firefox. If this door could be left open, it would allow us to continue with our development and hopefully lead to other, as yet unimagined, extensions.
I suppose we could try to set the URI immutable much later in the loading process (after content policies have run). That would complicate the code a good deal, though... So while it would be the simplest solution for the extension, it wouldn't be at all for the core code.
This seems like a duplicate of bug 421224. Marking as such, but please feel free to un-duplicate if I've missed something and this bug wants something different from that one.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 421224
You need to log in before you can comment on or make changes to this bug.