Translation changes selected value when using jQuery chosen plugin
Categories
(Firefox :: Translations, defect)
Tracking
()
People
(Reporter: martin.koerner, Unassigned)
References
Details
Attachments
(1 file)
|
124.98 KB,
text/html
|
Details |
Steps to reproduce:
I'm a developer using jQuery with chosen plugin.
A simple html page with complete JS is included.
It only contains a simple form with a html select tag - it is marked as english (<html lang="en">) despite much text is in german.
On a larger site, all select boxes are changed
Actual results:
- Call the site, don't change anything
- Open translation window from URL line
- Hit Submit button
Request will contain value "3" for the select field despite default should be "1" and the frontend did not change
Expected results:
- Call the site, don't change anything
- Open translation window from URL line
- Hit Submit
Request shoud contain value "1"
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Translations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
Hi Martin Körner , thanks for filing this!
This may be related to the behavior described in Bug 1919230 (comment 10).
Could you try to reproduce your example in Firefox Beta, and let me know if it reproduces there too?
If the behavior is fixed in beta, then it will very soon be fixed in the release channel.
If the behavior is not fixed in beta, then that will confirm that this behavior is something different, and we can investigate further!
Thank you!
|
Reporter | |
Comment 3•1 year ago
|
||
Hi Erik,
thanks for taking care of the issue.
I just loaded Firefox Beta 132.0b6 (64-Bit) and my example is still broken in there.
The behavior of Bug 1919230 seems to be very similar, but only handles <input> tags, while my problem is related to <select> and <option> tags (which are hidden, because of the jQuery plugin)
Following additional notes:
- If I add 'translate="no"' to the option tag, they won't be translated and the bug doesn't occur. But it's not expected for app developers to add this flag, or is it?
- If I add 'translate="no"' to the global <html> tag, it has no impact
- I think, translating the options isn't the problem for itself - the problem is, that the change event for the jQuery plugin is triggered and therefore the last option is chosen with no user interaction (and no visibility to the user)
|
||
Comment 4•1 year ago
|
||
It looks like the plugin is reading the live presentational DOM component values, which the translation modifies, and something in the logic is different. The behavior doesn't reproduce on Safari or Chrome, but I notice that we translate the DOM before it is visible for the user, so perhaps there is something in the timing difference between them. The moment you change the input the problem corrects itself. I couldn't reproduce this problem in a test case, and I can't really reason with the plugin's code as the script is written in Coffeescript, and I'm finding it a bit impenetrable to read.
add_task(async function test_select_value() {
const { translate, htmlMatches, cleanup, document } =
await createDoc(/* html */ `
<select>
<option value="1">Eins</option>
<option value="2">Zwei</option>
<option value="3">Drei</option>
</select>
`);
translate();
const select = document.querySelector("select");
is(select.value, "1");
await htmlMatches(
"Option values are not changed",
/* html */ `
<select>
<option value="1">EINS</option>
<option value="2">ZWEI</option>
<option value="3">DREI</option>
</select>
`
);
is(select.value, "1");
cleanup();
});
|
|
||
Comment 5•1 year ago
|
||
The severity field is not set for this bug.
:gregtatum, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 8•1 year ago
|
||
The provided example no longer seems to work, and based on Comment 7, the issue should now be fixed.
@Martin Körner, could you confirm if everything is working as expected on your end in Firefox 134.0b9? If the issue persists, please provide an updated test case to help us investigate further.
|
|
Reporter | |
Comment 9•1 year ago
|
||
I wasn't able to test a Beta-Version, but can confirm, that my issue doesn't exist in Firefox 134.0
|
|
||
Comment 10•1 year ago
|
||
Thank you for letting us know. I'll go ahead and mark this issue as WORSFORME.
Description
•