Opened 9 years ago

Closed 5 years ago

#5196 closed defect (fixed)

Translate breakage in Chrome

Reported by: pde Owned by: aaronsw
Priority: Immediate Milestone:
Component: HTTPS Everywhere/HTTPS Everywhere: Chrome Version:
Severity: Normal Keywords:
Cc: agl, mikeperry, pde, pam@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


With HTTPS Everywhere 2012.2.9 active, Google Chrome's built-in translation functionality does not work. 

This may be a ruleset bug related to #4122, or something more fundamental.  Marking as "blocker" since HTTPS Everywhere for Chrome can't be beta until we figure this out.

Child Tickets

#5224closedpdeAllow rulesets to be different in Firefox and Chrome releasesHTTPS Everywhere/EFF-HTTPS Everywhere

Change History (8)

comment:1 Changed 9 years ago by aaronsw

Cc: agl added

The issue seems to be that is changed to to and the latter page returns 404.

Reported to agl:

But in the meantime, you should probably just exempt from the rule.

comment:2 Changed 9 years ago by pde

Cc: mikeperry added

I'm still learning how to use the Chrome developer tools, so I'm not supremely confident about what I'm seeing yet.  However, here's what I see in the "Network" tab (after having right-clicked in Console and enabled "Log XMLHTTPRequests"

It seems that Chrome starts with a to POST to , but the next line in the logs is a GET to .  There is a postData payload for the POST that is of course missing in the GET.

I would be okay disabling the rewrite rules in order to push a beta release out the door, if I didn't have this niggling fear that we might be rewriting all POSTS to GETs.  We should rule that possibility out, which means finding a nice clean test case on some other site we can look at.

comment:3 Changed 9 years ago by pde

Cc: pde added

comment:4 Changed 9 years ago by pamg

Cc: pam@… added

comment:5 Changed 9 years ago by pde

Matt Perry sent this by email:

OK, upon further investigation, it is not related to the fact that this is a POST request. It's actually caused by a conflation of 2 implementation details in Chrome:

  1. The translate request is done using a XMLHttpRequest from the context of the main page. In this case, the translated page is requesting
  2. The webRequest API rewrites URLs by simulating a redirect. When HTTPS Everywhere tells us to redirect http://foo to https://foo, we actually simulate a redirect internally.

Because of (1), the redirection in (2) is considered cross-origin (the security origin is that of the main page, and the redirected URL's origin is Chrome (specifically, WebKit) blocks this cross-origin redirect.

I could be misunderstanding web security policy, but it seems like a bug to me. I don't see why redirecting an XMLHttpRequest from to should care about the security origin of the containing page.

In any case, it's a Chrome issue. I think your only workaround is to exempt from the rules.

comment:6 Changed 9 years ago by pde

Resolution: fixed
Status: newclosed

The workaround is now in git master.

comment:7 Changed 6 years ago by 6h72Q484AddGha8H

Resolution: fixed
Status: closedreopened

Google Translate appears to work fine now for me, so this rule could be re-enabled if someone else can confirm too...

comment:8 Changed 5 years ago by virgilgriffith

Resolution: fixed
Severity: Normal
Status: reopenedclosed

Google Translate works for me too under these conditions, e.g., .  Closing.

I am glad that we can finally clear this aaronsw ticket.

Note: See TracTickets for help on using tickets.