I have no issue with the translations in the front-end, but in the html, the field <input ReturnUrl> (and others) seems to undergo a translation as well, which results in a broken link
Categories
(Firefox :: Translations, defect)
Tracking
()
People
(Reporter: s.franken, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0
Steps to reproduce:
I try to log in to a website with a valid and existing user.
When the browser translates the login page (every language, but first discovered with German), the translations are fine.
I fill my email address and press next.
I get an empty screen.
Actual results:
So, what we could find is that the translations seem to also happen in the HTML input fields for the input=returnUrl and the input=confirmationToken. These fields are hidden and have no business being translated. i.e. Underscores were translated to '-' and there was a double redirect in the URL suddenly.
My co-worker did not have this issue and he was on version 127, and I am on 130.
When he installed 130, he could also reproduce the issue that login was not possible with translated pages.
We have tried to implement translate="no", but Firefox does not seem to adhere to this solution.
We have tried with other browsers and versions and the issue seems to only be in version 130.
Expected results:
That the user is able to land on the password field, even after the browser translated the page.
|
||
Updated•1 month ago
|
|
||
Comment 1•1 month ago
|
||
Hi Sanne Franken, thanks for reporting this!
I believe this was reported and fixed in Bug 1919230 (comment 10), which targets the Firefox 132 branch.
Firefox 131 (which released today) is still affected.
Could you please double check for me that Firefox 132 Beta (download page) has fixed the specific scenario that you've reported?
|
Reporter | |
Comment 2•1 month ago
|
||
Hello,
Ah right, I wasn't able to find anything similar to our issue in the current bugs, but I missed the one you mentioned.
It is indeed the same issue we experienced.
And it looks like 132 beta does indeed solve our problem and we don't even need the translate='no' in the class.
Thank you for the quick reply!
Sanne
|
|
||
Updated•1 month ago
|
|
|
||
Comment 4•1 month ago
•
|
||
Sanne,
Thank you for confirming the fix in Firefox 132 beta!
Since this is the second bug report of this regression (only Firefox 130 and 131 are affected), I have checked with the release managers and nominated the fix to be uplifted from 132 beta into the 131.0.x planned dot release.
Hopefully this will be fixed for you in Firefox 131 when the dot release is available in mid October.
Description
•