Opened 4 years ago

Closed 5 weeks ago

#5196 closed defect (fixed)

Translate breakage in Chrome

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


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

#5224Allow rulesets to be different in Firefox and Chrome releasespde

Change History (8)

comment:1 Changed 4 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 4 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 4 years ago by pde

  • Cc pde added

comment:4 Changed 4 years ago by pamg

  • Cc pam@… added

comment:5 Changed 4 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 4 years ago by pde

  • Resolution set to fixed
  • Status changed from new to closed

The workaround is now in git master.

comment:7 Changed 9 months ago by 6h72Q484AddGha8H

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 weeks ago by virgilgriffith

  • Resolution set to fixed
  • Severity set to Normal
  • Status changed from reopened to closed

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.