1006347 - Google Translate does not translate full pages in Firefox 29

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Tristan Nitot]

STR : 

1 - visit https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fstandblog.org%2Fblog%2F
2 - See Google translate toolbar but not translated content

Expected result : see French page translated into English as with other browsers (tried Chrome and Safari).

Please note that translation of a chunk of text does work. What's broken is translation of a page for which a URL is typed.

Comment 1

[Karl Dubost💡 :karlcow]

The error message is about "This page was not retrieved from its original location over a secure connection." Which seems to be about mixed content policy.

The message in the console is

"Load denied by X-Frame-Options: http://translate.google.com/translate?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/ does not permit cross-origin framing."

Comment 2

[Karl Dubost💡 :karlcow]

I will contact Alex at Google.

Comment 3

[Karl Dubost💡 :karlcow]

See https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

→ http --print hH GET "http://translate.google.com/translate?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/"

GET /translate?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/ HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, compress
Host: translate.google.com
User-Agent: HTTPie/0.8.0

HTTP/1.1 200 OK
Alternate-Protocol: 80:quic
Cache-Control: no-cache, must-revalidate
Content-Language: en
Content-Type: text/html; charset=ISO-8859-1
Date: Tue, 06 May 2014 10:24:03 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Server: HTTP server (unknown)
Set-Cookie: PREF=ID=5a0868598706d030:TM=1399371843:LM=1399371843:S=TK3axbZBy9VX0zo-; expires=Thu, 05-May-2016 10:24:03 GMT; path=/; domain=.google.com
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

Comment 4

[Karl Dubost💡 :karlcow]

This is working btw. 

http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fstandblog.org%2Fblog%2F

Note  the difference in between HTTP and HTTPS for the beginning

Comment 5

[Karl Dubost💡 :karlcow]

Understanding the user scenario.

1. a user enters http://translate.google.com/  (HTTP)
2. Google does automatic redirection to https://translate.google.com/ (HTTPS)
3. User enter an HTTPS URI, for example, http://standblog.org/blog/ 
4. Request the translation

The iframe is failing due to the mixed-content policy.

What Google could do. When the URI is http only, allow to redirect to http only.

Comment 6

[Karl Dubost💡 :karlcow]

I meant 
"3. User enter an HTTP only URI, for example, http://standblog.org/blog/ "

Comment 7

[Karl Dubost💡 :karlcow]

Alex has been contacted.

Comment 8

[Tanvi Vyas[:tanvi]]

The yellow dialogs that appear seem to be from google and not from Firefox.  We don't block any mixed content on these pages by default (there is mixed display content, but it isn't blocked).  Is this issue new to Firefox 29?  Does the page work in previous releases?  There has been nothing new added to the MCB since maybe FF 26.

I get the same yellow warning on safari (This page was not retrieved from its original location over a secure connection.), but in that case, the translated page actually shows up.  Safari doesn't have a Mixed Content Blocker, but we do notice that you lose the "https" and the lock icon when you visit:
https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fstandblog.org%2Fblog%2F&sandbox=1

compared to
https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=https%3A%2F%2Fstandblog.org%2Fblog%2F&sandbox=1

Comment 9

[Karl Dubost💡 :karlcow]

Tanvi: Yup the dialogue is from Google (nobody said it was from Firefox) but that's not the issue. ;)

https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fstandblog.org%2Fblog%2F&sandbox=1
For Safari, it displays messages in the console and go ahead with displaying the insecure page. They have indeed not yet implemented the Mixed Content Blocker. :) It will eventually break if they do implement. Chrome too.

Comment 10

[Tanvi Vyas[:tanvi]]

The Mixed Content Blocker is not invoked on the google translate page.  No content is being blocked by it.  (If there was blocked content, you would see a shield in the url bar - https://people.mozilla.org/~tvyas/FigureA.jpg)  The reason that we can't render the frame is because of the pages X-Frame-Options policy, that specifies which pages are allowed to frame it.

Headers show that 

http://translate.google.com/translate?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/ [url 1]

has a policy of:
x-frame-options: SAMEORIGIN

This means the page can only be displayed in a frame on the same origin as the page itself.  Since the origin of the page is https://translate.google.com, it is not the same.

I'm not sure why https://translate.google.com is trying to embed http://translate.google.com here.  Why is this working for other browsers (i.e. chrome) that also implement x-frame-options?  Does this have to do with our redirect issues?  I see the following 302 in the headers, going from https://translate.googleusercontent.com to [url 1].  (At first glance, it doesn't look like a gecko redirect bug.)

https://translate.googleusercontent.com/translate_c?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/&usg=ALkJrhjdWBWLzYtCo4LF-W_mmgG5CnMOjg

GET /translate_c?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/&usg=ALkJrhjdWBWLzYtCo4LF-W_mmgG5CnMOjg HTTP/1.1
Host: translate.googleusercontent.com
User-Agent: ... Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

HTTP/1.1 302 Found
Alternate-Protocol: 443:quic
Cache-Control: no-cache, must-revalidate
Content-Language: fr
Content-Length: 335
Content-Type: text/html; charset=UTF-8
Date: Mon, 12 May 2014 22:03:38 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Location: http://translate.google.com/translate?depth=1&hl=en&rurl=translate.google.com&sl=fr&tl=en&u=http://standblog.org/blog/
Pragma: no-cache
Server: HTTP server (unknown)
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Firefox-Spdy: 3.1

In the HTTP version of the page, there are no 302s.  This requires further debugging to figure out why it's working for Chrome and not Firefox.  Is it a bug on our side, or is it actually googles x-frame-options policy that is correctly causes gecko to block the iframe.


(In reply to Karl Dubost :karlcow from comment #9)
> For Safari, it displays messages in the console and go ahead with displaying
> the insecure page. They have indeed not yet implemented the Mixed Content
> Blocker. :) It will eventually break if they do implement. Chrome too.

The MCB is implemented in Chrome but not in Safari.

Comment 11

[Kohei Yoshino]

Sorry about the false alarm.

Comment 12

[Caspy7]

I recently experienced this issue.  Instead of troubleshooting it, it was easier to just open it in Chrome and forget about it.
I imagine there are many who are less technical who do the same, though for those who need frequent translation, decide that Firefox is broken and move elsewhere.

I've experienced it several times now and seen multiple reports from others.  
I feel like this is an issue that, even though it may be technically someone else's fault, will be viewed as ours.  And if they don't move to fix it, we should work to mitigate it forthwith.

Comment 13

[Karl Dubost💡 :karlcow]

Sent update to Google, and a reminder.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

Google confirmed a fix that I have verified using the STR in comment 5.

Comment 15

[Tristan Nitot]

Just tested and it works. A huge thank you for those who helped fix this bug: Karl, Lawrence & others!

Comment 16

[Tanvi Vyas[:tanvi]]

Was the root cause their X-Frame-Options policy?