Opened 2 years ago

Closed 2 years ago

#5196 closed defect (fixed)

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:

Description

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

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

Change History (6)

comment:1 Changed 2 years ago by aaronsw

  • Cc agl added

The issue seems to be that http://translate.googleapis.com/translate_a/t?anno=3&client=te_lib&format=html&v=1.0&logld=v7 is changed to to https://translate.googleapis.com/translate_a/t?anno=3&client=te_lib&format=html&v=1.0&logld=v7 and the latter page returns 404.

Reported to agl: https://twitter.com/aaronsw/status/172094187221696514

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

comment:2 Changed 2 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 http://translate.googleapis.com/translate_a/t?anno=3&client=te_lib&format=html&v=1.0&logld=v7 , but the next line in the logs is a GET to https://translate.googleapis.com/translate_a/t?anno=3&client=te_lib&format=html&v=1.0&logld=v7 .  There is a postData payload for the POST that is of course missing in the GET.

I would be okay disabling the translate.google.com 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 2 years ago by pde

  • Cc pde added

comment:4 Changed 2 years ago by pamg

  • Cc pam@… added

comment:5 Changed 2 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 http://translate.googleapis.com/...
  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 translate.googleapis.com). 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 http://translate.googleapis.com to https://translate.googleapis.com 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 translate.googleapis.com from the rules.

comment:6 Changed 2 years ago by pde

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

The workaround is now in git master.

Note: See TracTickets for help on using tickets.