claustromaniac / httpz

Fat-free hardenable opportunistic encryption for Firefox
https://addons.mozilla.org/firefox/addon/httpz/
GNU General Public License v3.0
62 stars 5 forks source link

Whitelist, remove from whitelist, presence of listing #45

Closed grahamperrin closed 5 years ago

grahamperrin commented 5 years ago

http://thegearcalculator.appspot.com/

Screen recording:

  1. 01:35 addition to whitelist (because the content is wrong with https)
  2. 01:45 (page action) apparent removal from the whitelist, automated reload of the http URL
  3. 01:49 page action unavailable, greyed out
  4. 02:00 presence in the whitelist
  5. 02:13 restart of Firefox
  6. 02:24 page action available, with the option to remove from the whitelist.

In this case: step (2) is probably not a sane action (no sane user would require the wrong content), however the presence of the listing at point (4) on the timeline seems inconsistent with the click to remove the listing at step (2).

Edge case? Or is this somehow related to the criteria at https://github.com/claustromaniac/httpz/issues/42#issuecomment-555548485?

TIA

claustromaniac commented 5 years ago

I could not reproduce this myself, but I think I know what is going on on your end. If my guess is right, it is a regression I just introduced in 0.10.1

claustromaniac commented 5 years ago

Please test 0.10.2b. Thanks in advance 😸

grahamperrin commented 5 years ago

0.10.2b

Testing with cleared history then a refreshed profile etc.: AFAICT an initial visit to the page results in automatic redirection to https without the page action icon. I/we should probably take a rest now :-) I'm happy to continue this at the weekend, no expectation that you should fix things so quickly …


PS and if I'm not mistaken, switching enhanced tracking protection off is enough for the page action to appear in this situation.

Then, whitelist the site, the page action icon disappears, switch enhanced tracking protection on and the page action reappears.

Gut feeling: not a conflict with enhanced tracking protection, but throwing the switch is enough to trigger (re)appearance of the page action. Other things might have a comparable trigger effect.

Race condition? Timing?

claustromaniac commented 5 years ago

Tracking Protection should have no direct influence whatsoever. What is likely to change when you flip Tracking Protection (that can affect this extension's apparent behavior), is that sites are most likely not fetched from the memory cache immediately afterwards.

To clear any doubts: disable disk and memory cache (yes, both) in about:config before testing. The prefs you have to set to false are browser.cache.disk.enable and browser.cache.memory.enable. If you see the same misbehavior then, something is likely wrong with the extension, otherwise, it was the memory cache messing with the tests all along (not this extension's fault).

claustromaniac commented 5 years ago

I initially could not reproduce the incongruity described in the OP, and I still can't. 0.10.2 fixed the only thing that I imagine could cause that, the only thing that makes sense.

I'm closing this issue. If you still can reproduce it, please let me know and I will re-open.

Thanks.