Opened 4 years ago

Last modified 7 months ago

#5196 reopened defect

Translate breakage in Chrome

Reported by: pde Owned by: aaronsw
Priority: blocker Milestone:
Component: HTTPS Everywhere: Chrome Version:
Keywords: Cc: agl, mikeperry, pde, pam@…
Actual Points: Parent ID:
Points: 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

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

Change History (7)

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 7 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...

Note: See TracTickets for help on using tickets.