Able to reproduce the issue on win8.1, mac and linux and observed that clicking "YES" or "NO" navigates to https://www.tablesolution.com/undefined after translating the page to English.

This can be seen from M30 builds to latest canary

Confirming the issue for more inputs on this

I can't reproduce this on Linux with v50.0.2661.102.

As far as I am aware, we don't automatically navigate on translate completion. We do send messages to the JavaScript layer about language detection and translation events, and in principle it might be somehow possible for the site developers to hook into these and try to navigate on behalf of the user:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/translate_internals/translate_internals.js

I don't see anything obvious in the handler c++ code that would indicate any kind of automatic navigation:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/webui/translate_internals/translate_internals_handler.cc

Do you have any plugins installed that might be causing this behaviour?

We've reproduced this on both Windows and Mac (two separate machines) so I doubt it's plugin related.

Here's screen-by-screen to reproduce, please confirm you've followed exactly:

Deleted: 1.png 700 KB

	1.png 700 KB View Download

Deleted: 2.png 1.0 MB

	2.png 1.0 MB View Download

Deleted: 3.png 207 KB

	3.png 207 KB View Download

Sorry, I misunderstood the original entry. Yes, this reproduces for me now. This looks like a problem with the "locale-select" logic in the page, which is obfuscated and minified and is best left to the page authors to debug. It seems likely that the javascript tries to get locale information out of a mapping it maintains internally and navigate to the right URL. I'd suggest digging into that logic to figure out what the mapping information is and how it is bound/read.

If you find that something in the browser's language information as exposed to the Javascript API is broken, that is something we can investigate; but it's equally likely at this point that it's a bug in the developer's script that is managing this transition.

PS - If your mapping is kept around in plain-text, like in a hidden div, it is entirely possible that the text is being translated. AFAIK translate should not touch any <script> blocks at all, nor should it translate href attributes etc.

Hi Andrew thanks for investigating this.

Here's the relevant coffeescript for this (I'm the owner of the page)

    $('.locale-select').click (event)=>
      event.preventDefault()
      $target = @$(event.target)
      @storeLocale($target.data('locale'))
      window.location = $target.attr('href')

The problem is that $target.attr('href') is returning undefined; this only happens AFTER Chrome translate.

$target.prop('href') gives the same result.

OK this seems to work:

    $('.locale-select').click (event)->
      event.preventDefault()
      $target = LocaleDetect.$(@)
      LocaleDetect.storeLocale($target.data('locale'))
      window.location = $target.attr('href')

I guess Chrome Translate breaks jQuery's event.target?

Tested in win7, win10 & OSX 10.11.5 on stable version 51.0.2704.63 m. Looks issue fixed.
when click on "YES" navigating https://www.tablesolution.com/en/index.html
when click on "NO" nothing happend.

Thank you.

@mummare...@chromium.org

Actually I applied the workaround to the page. The bug still exists in Chrome. Here is a generic description:

1) If I have any element that contains translatable text
2) AND I add a jQuery event listener to that element, and the callback function references event.target
3) AND I click "Translate to English..." in Chrome
4) THEN when the callback function fires, any attempt to do $(event.target).attr('xxx') (where xxx is any HTML attribute) will return undefined.

As a workaround, calling $(this) instead of $(event.target) will allow you to fetch the data.

Got it, thanks for the clarification.

This might not be a bug in Chrome as such, but perhaps a side effect of the way that translation works. IIRC a script is downloaded from the Google Translate servers and it goes through and modifies the page content; it's conceivable that those modifications mess with the DOM elements in a way that makes jquery unhappy in this specific case (or more generally).

My expertise here is on how language detection functions.

Kenji, do you know who would be a better person to loop in on this?

We've just received a suspiciously similar report in  issue 616744  saying that translate is altering CSS.

Removing myself since I don't work on Translate anymore.

The code change need to from Google Translate Element. Internal bug id is 29872734

rename this bug to "event handler depend on attribute of element break by translation"

Simplified example to show the problem
<html>
 <body>
   <span id=id1 love=good>text</span>
  <script>
   function myclick(event) {
     event.preventDefault();
     document.write("event.target: " + event.target.getAttribute("love") + "<br>");
     document.write("event.currentTarget: " + event.currentTarget.getAttribute("love") + "<br>");
     document.write("this: " + this.getAttribute("love") + "<br>");
     return true;
   }
   document.getElementById("id1").onclick=myclick;
  </script>
 </body>
</html>

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot