+++ This bug was initially created as a clone of Bug #1078740 +++ Filing this so that the idea doesn't get lost. Once a user has given permission using the "Unblock" button in the notification bar, the user has to go into the Data Manager and has to figure out how to revoke the permission there when he/she changes his/her mind about unblocking that page later. As was pointed out, this is after the fact (i.e., some revealing information has already been sent to the website in question), but may be appreciated by the user anyway to avoid future incidences. (Quoting neil@parkwaycc.co.uk from bug 1078740 comment #4) > (In reply to from bug 1078740 comment #3) > > (In reply to rsx11m from bug 1078740 comment #2) > > > Also, once "Unblock" has been selected, there is no obvious way to block > > > again in the warning bar (but then, that's after the fact anyway). Thus, a > > > possible thought might be to add a "Block Again" button (which probably > > > would/should be inherited by the SSL warnings too for consistency, if that's > > > the way to go). > > Hmm, I would have to find out what whether the SSL warning can do this > OK, so if the SSL mixed active content gets unblocked then > activeBrowser.docShell.mixedContentChannel will become non-null and if we > want to block it again we need to clear it and reload the page. (Quoting rsx11m from bug 1078740 comment #5) > (In reply to neil@parkwaycc.co.uk from bug 1078740 comment #3) > > (And isn't it too late anyway?) > > That's certainly the main point and made me thinking twice about this > suggestion as soon as I came up with it. Thus, if it appears to be > additional work that's not worth much in actually providing any protection > for the user, let's stick with simply opening the global preferences only. > We can add some additional information to the Help content there and point > the user to the Data Manager.