338181 - Do something wise with meta refresh blocking

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Mark Mentovai]

Bug 83265 gives the ability to block meta refreshes in an nsIWebProgressListener2 callback.  The basic implementation carries the old behavior over, which is to not block anything.  At the very least, Camino should support accessibility.autorefresh as a hidden pref with no UI.  Better yet, Camino should offer a refresh-blocked notification like it does for blocked popups.

Comment 1

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

This would be another item for the info bar and definitely improves accessibility (which is why it was implemented in core).

Comment 2

[Chris Lawson (gone)]

Wait, then what the heck does

http://kb.mozillazine.org/Hostperm.1#refresh

do?

cl

Comment 3

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

Or permissions.default.refresh, which should allow people to disable refresh entirely, across-the-board (like permissions.default.image allows people to prevent the loading of all images).

Comment 4

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

(In reply to comment #2)
> Wait, then what the heck does http://kb.mozillazine.org/Hostperm.1#refresh do?

It describes the content blocker's "refresh" type, which is pretty useless, since from what I can see no one ever asks the content blocker about it. :)

Comment 5

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

(In reply to comment #3)
> Or permissions.default.refresh, which should allow people to disable refresh
> entirely, across-the-board (like permissions.default.image allows people to
> prevent the loading of all images).

I'd like to be proved wrong, but as I said above, I don't think this preference actually does that, since I can't see anyone calling ShouldLoad, ShouldProcess or TestPermission for "refresh" (aContentType == 8).

Comment 6

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

Presumably bug 83265 now gives us the ability to do something wise now on the trunk.

Comment 7

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

Not going to make 2.0 as-is; patches welcome.

Comment 8

[Chris Lawson (gone)]

(In reply to comment #4)
> (In reply to comment #2)
> > Wait, then what the heck does http://kb.mozillazine.org/Hostperm.1#refresh do?
> 
> It describes the content blocker's "refresh" type, which is pretty useless,
> since from what I can see no one ever asks the content blocker about it. :)

Well, *something* must be asking about it, because it works as far as I can tell. At least, adding "toolmonger.com" to the refresh blocking list (manually via SQLite Database Browser for the moment) in a trunk nightly stops the horribly annoying five-minute auto-refresh on that site.

I haven't tried the Gecko pref in comment 3.

Comment 9

[Chris Lawson (gone)]

Never mind. The page I was testing with was reloading so quickly in the background that I never noticed it happening until I saw it in the foreground. So yeah, that doesn't actually seem to do anything.

Comment 10

[Chris Lawson (gone)]

By the way, Gavin, do you know if there are bugs filed on:

* nothing ever asks the content blocker about refresh entries in hostperm.sqlite
* nothing ever asks about the permissions.default.refresh pref

Because if there aren't, there should be. It's sort of silly to have things that supposedly do something but don't.

Comment 11

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

(In reply to comment #10)
> * nothing ever asks the content blocker about refresh entries in
> hostperm.sqlite
> * nothing ever asks about the permissions.default.refresh pref
> 
> Because if there aren't, there should be. It's sort of silly to have things
> that supposedly do something but don't.

I don't know if there are existing bugs on this. As far as I can tell we don't "have things" at all, apart from some wiki page on mozillazine :)

Comment 12

[Chris Lawson (gone)]

Well, since the content blocker has a "refresh" type in the first place, shouldn't it be, you know, *functional*? If the answer to that is no, then it's dead code and should be removed.

Comment 13

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]