Opened 9 years ago

Closed 9 years ago

#4527 closed defect (fixed)

Rule list context menu doesn't get cleared for new https urls

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: HTTPS Everywhere/HTTPS Everywhere: Chrome Version:
Severity: Keywords:
Cc: pde, aaronsw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Due to the fact that we don't listen to https url events for onBeforeRequest, we do not have a way to clear stale rules from the url bar when the user manually navigates to a new URL (for example, visits "" and then types in "" the eff rules will remain displayed on the Google page). We don't want to listen to blocking https onBeforeRequest events because this would impede performance.

This bug is way more tricky than it seems. There are several possible solutions. I've tried the following four, and none of them really have worked out so far.

  1. Listen to onBeforeRequest async for https (

I tried purging the rules whenever we had a details.type == "main_frame" and an https scheme in the async handler, but this causes premature rule clearing for redirects unless you also listen to onBeforeRedirect. If you do listen to onBeforeRedirect, it still fails on JS redirects. has a JS redirect to

  1. Listen to tabs.onUpdated async (

Had similar issues to #1, with some additional event ordering problems.

  1. Track rule destination urls used for each tab

In desperation, I even tried tracking the destination URL from our url engine for each tab, with the intention of clearing the list if the current URL differed from the last rule url.

However, I was again defeated by the inability to detect JS redirects.

  1. Listen to WebNavigation.onCommitted for details.transitionType == "typed" and possibly also "link" (

This was the most promising, because we could use it to clear the rule sets when we detected a user-driven navigation to a new https url.

However, transitionType == "typed" is still set for redirects that happen after a typed URL (and possibly for all JS redirects). This seems like an API bug to me. Should we file one?

It seems like we might be left with just adding some heuristics to option 3 only clear the rules if the domain smells different enough?

Child Tickets

Change History (2)

comment:1 Changed 9 years ago by mikeperry

mikeperry/bug4527-urltracking has my attempt for option 3. I did not save the other attempts.

comment:2 Changed 9 years ago by pde

Resolution: fixed
Status: newclosed

I think Mike fixed this a while ago.

Note: See TracTickets for help on using tickets.