HTTPS Everywhere android doesn't show applicable rules on error pages

[diracdeltas]

To repro, turn on the broken PCWorld rule in Firefox for Android. Go to PCWorld, which shows a server error page. Click on the HTTPS Everywhere icon.

Expected: PCWorld rule is listed.

Actual: no rules are shown

[jeremyn]

I can confirm this is still an active problem. It's annoying because after following @diracdeltas 's instructions:

• visit http://www.pcworld.com on Firefox/Android
• enable this PCWorld rule
• Observe "Unable to connect" page

I don't know how to re-disable the rule. Anyone know how?

[wonderchook]

@jeremyn is this resolved for you? I just tried to recreate and I'm not getting the "Unable to connect"

[jeremyn]

@wonderchook It looks like the PCWorld rule has been fixed, compare

https://github.com/EFForg/https-everywhere/blob/375124aa311c82db8c87c1882c41b082da4b84a4/src/chrome/content/rules/PCWorld.xml (old version that I link in my previous comment)

to

https://github.com/EFForg/https-everywhere/blob/ff3dfc21e72712b23a050c8cc48432cd5a25e0f3/src/chrome/content/rules/PCWorld.xml (current version)

However the actual problem reported is with the add-on's UI in Firefox. This has been totally modified with WebExtensions and per @Hainish is lacking, see his comment at #9958 (comment). I can't even find an HTTPS Everywhere UI on the Android device I'm checking.

So this specific issue is "resolved" for me because the entire UI is gone.

[wonderchook]

Hmmm so this is what I see in the web UI. I clicked on the 3 dots in the upper right hand corner of Firefox to bring it up.

[jeremyn]

Okay, I checked again and the HTTPS Everywhere UI is there now, or it came back. I'm not sure what happened when I looked earlier.

I looked around for a new ruleset to test with and it seems I can reproduce the original problem, or something like the original problem, with https://github.com/EFForg/https-everywhere/blob/7e4193f45aeb4633e79cdfa56abe1178bf746b39/src/chrome/content/rules/Deluge.xml (current master) and http://deluge-torrent.org . Try something like this:

• Go to http://deluge-torrent.org on the device
• Open the HTTPS Everywhere UI and enable the Deluge-torrent.org ruleset
• Observe the Unable to connect error
• If you check the UI now, you might still see the rule
• However, quit Firefox (three dots > Quit) with the "Clear private data on exit" setting enabled in Settings > Privacy
• Reopen Firefox, go to http://deluge-torrent.org , and observe the Unable to connect error
• Now if you open the HTTPS Everywhere UI, you (incorrectly) should not see any rulesets listed, including Deluge-torrent.org

What do you get when you try that?

[wonderchook]

Same results as you, the ruleset was not listed. So the actual bug is that the ruleset disappears from the UI then?

[jeremyn]

Yes.

[Hainish]

I can reproduce this. Additionally, it looks like the rulesets disappear from every other page - try freerangekitten.com after following the steps above.

[Hainish]

This appears only to be the case for the first tab opened after a restart. Subsequent tabs seem to display the rulesets properly.

[Hainish]

The debugging console for Fennec doesn't show much useful output here.

[jeremyn]

@Hainish I've used the device I tested on earlier, since testing, so this doesn't follow directly from my earlier comment. Anyway I can see the Freerangekitten.com ruleset when I look at the HTTPS Everywhere UI from https://freerangekitten.com but I don't see the Deluge-torrent.org ruleset when I open the UI from https://deluge-torrent.org. So I'm only partially verifying what you are seeing.

[wonderchook]

I just went through the steps again and it appears it is the first tab that has the issue.

[jeremyn]

I misunderstood what was meant by "first tab". I can confirm now that if I open three tabs, and then open the HTTPS Everywhere UI from the second or third tab, the ruleset checkboxes are there. The checkboxes are missing when I open the UI from the first tab. So I can confirm what @Hainish and @wonderchook are seeing.

[Hainish]

The problem with this is the tabId is 0, which (when sent via sendMessage caused packet.object to be undefined rather than 0 when requesting active rulesets from background.js.

This is fixed in #14487