Opened 6 years ago

Closed 6 years ago

#9505 closed defect (fixed)

"Waiting for extension HTTPS Everywhere" - unable to connect to any website

Reported by: realityexists Owned by: pde
Priority: Very High Milestone: HTTPSE Cr 2013.8.17
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version: HTTPS-E chrome 2013.8.16
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Chrome 28.0.1500.95 m, HTTP Everywhere 2013.8.16

I've had HTTPS Everywhere installed for a while without any issues, but right now I cannot connect to any website (https or http) with it enabled. No page content is shown and the toolbar says:

Waiting for extension HTTPS Everywhere

As soon as I disable HTTPS Everywhere I can browse fine again.

Child Tickets

Change History (11)

comment:1 Changed 6 years ago by cypherpunks

Yeah - experiencing this on two systems running Chrome.

What's unusual is that if you can get in and turn it off - then open a few pages - turn it back on... and no problems from there. It's the initial restoration of windows that spikes the CPU and hangs.

Ghostery may be a conflicting extension in my two cases but I did try to disable that too and restart, same problem.

comment:2 Changed 6 years ago by realityexists

I'm running Ghostery as well, but that's also been installed for a long time without issues - until now.

comment:3 Changed 6 years ago by cypherpunks

I am not running Ghostery and experiencing the same issue.

comment:4 Changed 6 years ago by cypherpunks

I've tried with just HTTPS Everywhere in extensions and nothing else. Same problem. If it is restoring tabs it spikes the CPU and then nothing loads or takes a very long time until you can get into the extensions tab and disable it (if you can get in because it's not dragging).

Even the chrome:// pages stop responding if you're trying to troubleshoot when this happens. Mac Chrome.

comment:5 Changed 6 years ago by cypherpunks

Same issue here - gets stuck on "Waiting for extension HTTPS Everywhere" and spikes the CPU. Running this on Chrome in Windows alongside Facebook Disconnect, DoNotTrackMe and Pocket.

comment:6 Changed 6 years ago by Tracy

I am having the same "Waiting for extension HTTPS Everywhere" problem.

It hangs Chrome so badly that I can't even open Chrome "Tools" to disable the extension without Chrome crashing. Chrome completely unusable.

This just started this morning. Prior to this there were zero problems.

Running Windows 8 and did an update yesterday after which Chrome and the extension ran fine all day. All other computer programs running fine this AM.

comment:7 Changed 6 years ago by cypherpunks

+1 anonymous report

I have the same Chrome/HTTPSEverywhere versions as the reporter, and I'm only running AdBlock and FlashBlock.

Can anyone (maintainer or reporter) give instructions on how to debug this further? Is there some way we can give more detail on this without setting up a full blown development environment?

comment:8 Changed 6 years ago by Tracy

Of course, after being frustrated all morning and finally adding to this ticket - Chrome and the extension are suddenly both working fine.... The same magic that works when my car has a problem but when I finally take it to the mechanic and he drives it around the block to see what's going on, the problem disappears.

comment:9 Changed 6 years ago by pde

This is a real bug. The fix is being worked on over in #9507. In the mean time, you can downgrade to https everywhere 2013.7.10 for chrome. That's quite tricky to do because Google makes installation of extensions from anywhere but the Chrome web store a pain.

First, go to chrome://extensions and uninstall the buggy 2013.8.16 version.

Then, go to, find the link for 2013.7.10, right-click save-as that file, then go to a chrome://extensions tab and drag the downloaded file in there.

comment:10 Changed 6 years ago by Tracy

Actually, spoke too soon. Still broken.

Thank you, pde.

comment:11 Changed 6 years ago by pde

Milestone: HTTPSE Cr 2013.8.17
Resolution: fixed
Status: newclosed
Version: HTTPS-E chrome 2013.8.16

This should be fixed in the 2013.8.17. Please let us know if it isn't.

Note: See TracTickets for help on using tickets.