Open Bug 2019140 Opened 5 months ago Updated 4 months ago

Local translation does not work if javascript.options.wasm_baselinejit is set to false

Categories

(Firefox :: Translations, defect)

Product:
Firefox
Component:
Translations
Version:
Firefox 148
Type:
defect

Tracking

()

People

(Reporter: Wladmis, Unassigned)

References

Details

Attachments

(2 files)

image.png
398.25 KB, image/png
Details
image.png
24.01 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

  • Enter about:config
  • toggle javascript.options.wasm_baselinejit to false
  • Restart the browser
  • Select some text -> RMC -> "Translate selection to ..."

Actual results:

Error message "The was a problem translating. Please try again." appears.

Expected results:

The selected text translated.

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.

Component: Untriaged → Translations

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)

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.

I guess it is not supposed to belong to Firefox::Translations component, but I don't see how I could change it.

Attached image image.png —

I tried this out and I am unable to reproduce (see screenshot).

Just for good measure, :yury, do you have any idea why this may be the case for the bug reporter?

Flags: needinfo?(ydelendik)

Just for good measure, :yury, do you have any idea why this may be the case for the bug reporter?

I don't the issue see it with current nightly (macos). I'll check Linux later.

I've just recheck in on Linux (Flatpak) 148.0.2: reproduced. I should notice, that all other JS/WASM JIT options are disabled as well. But as I can see, only disabling javascript.options.wasm_baselinejit break this functionality.

Duplicate of this bug: 2026085

We have now had a second report of this happening in Bug 2026085, this time on macOS.

I still don't seem to be able to reproduce on either my macOS machine or my Linux machines.

Here is a snippet from comment 16 on Bug 2026085:

tl;dr: Found it. Can reproduce it. Fixed it. It is a bug related to Just In Time Javascript compilation settings. Whether it's something worth fixing is another matter, since it involves about:config, but I want to document it so anyone else encountering this issue can remediate it.

Details follow:

Background: If I set javascript.options.wasm_optimizingjit to false, translation fails. That doesn't explain why it broke on the upgrade, because I turned off most jit long ago, then restored javascript.options.wasm_optimizingjit to its default setting when I originally discovered that it blocked translation. I did not make any changes to those settings at the time I upgraded to Firefox 149.

I was able to fix my translation profile for 149 by removing all jit overrides I had set, restarting 149, and then reapplying them, being sure to leave javascript.options.wasm_optimizingjit at its default setting.

The weird part is that upgrading from 148 to 149 does not change the javascript.options.wasm_optimizingjit from its default setting, but acts as if it has done so. I am able to reproduce the problem on a virtual machine with a single profile.

Status: UNCONFIRMED → NEW
Ever confirmed: true

NI'ing Ryan Hunt also, as per our conversation on Matrix.

Flags: needinfo?(rhunt)
Severity: -- → S3

Not sure if Bug 2026085 is legitimately a duplicate of this bug. They're likely related, but separate.

Per bug 2019140, javascript.options.wasm_baselinejit triggers translation not working.
But for me, javascript.options.wasm_baselinejit is set to false, and translation is working just fine.

For me, setting javascript.options.wasm_optimizingjit to false breaks translation. I never filed it as a bug because I figured it's reasonable for Mozilla to set certain requirements for features to work. I suppose I could file it as a nice-to-have because I understand jit presents security issues but I don't really grok jit or why translation might depend on some of it.

But the bug in 2026085 is that upgrading from 148.0.2 to 149 causes Firefox to behave as if javascript.options.wasm_optimizingjit were set to false even though it's set to true.

You're definitely right that the two issues may be different, but related.

I mostly wanted to consolidate our context into a single place, and I've asked in the #Web Assembly channel on Matrix for help, since I am neither an expert on WASM internals, nor on JITs.

If they turn out to be entirely separate concerns, perhaps even with one behavior being expected, we can always update the resolutions and associations between the bugs as such.

Ooh, interesting. They're definitely related.

javascript.options.wasm_baselinejit true
javascript.options.wasm_optimizingjit true
Both settings at default.
Translation works.

javascript.options.wasm_baselinejit true
javascript.options.wasm_optimizingjit false
One setting at default, other not.
Translation works.

javascript.options.wasm_baselinejit false
javascript.options.wasm_optimizingjit true
Swap which setting is at default.
Translation works.

javascript.options.wasm_baselinejit false
javascript.options.wasm_optimizingjit false
Neither setting at default.
Translation doesn't work.

(In reply to Chas Belov from comment #11)

Setting both javascript.options.wasm_baselinejit and
javascript.options.wasm_optimizingjit to false will completely disable wasm
support. In which case, as seems likely to me, if the translation facility
does require wasm, it is likely to stop working.

I am also able to reproduce everything from comment 11 on both my macOS and Linux computers.

:Wladmis, can you confirm these steps as well? We may have no issue here if WASM is expected to not work with both prefs set to false..

Flags: needinfo?(ydelendik) → needinfo?(mzla)

Chas, one thing that I'm still uncertain of, is that you were reporting that you were just not seeing the Translations UI at all: the button wasn't showing, you didn't see the context menu item appear, etc.

When I run these steps, the Translations feature UI surfaces are available to me. They just fail when I attempt to use them.

Is it the same for you with these prefs? Were you able to figure out why the UI wasn't showing for you initially?

Flags: needinfo?(docorbit)

Running with javascript.options.wasm_baselinejit and
javascript.options.wasm_optimizingjit set to false, translation doesn't
work for me, with the following error text printed to the shell:

console.error: (new Error("Error loading Bergamot wasm module.", "chrome://global/content/translations/translations-engine.worker.js", 642))
console.error: Translations: "The engine failed to load for translating \"de -> en\". Removing it from the cache." "Error loading Bergamot wasm module."
console.error: "Error loading Bergamot wasm module."
JavaScript error: chrome://global/content/translations/bergamot-translator.js, line 576: RuntimeError: Aborted(Error: no WebAssembly compiler available). Build with -s ASSERTIONS=1 for more info.

(In reply to Erik Nordin [:nordzilla] from comment #13)

I am also able to reproduce everything from comment 11 on both my macOS and Linux computers.

:Wladmis, can you confirm these steps as well? We may have no issue here if WASM is expected to not work with both prefs set to false..

Confirm. If both of them are set to false, translation does not work.

Flags: needinfo?(mzla)

(In reply to Erik Nordin [:nordzilla] from comment #13)

I am also able to reproduce everything from comment 11 on both my macOS and Linux computers.

:Wladmis, can you confirm these steps as well? We may have no issue here if WASM is expected to not work with both prefs set to false..

If one of them is set on true, it works.

Question: do I get it right, that WASM cannot work without JIT? Is it by design?

(In reply to [:Wladmis] from comment #18)

Question: do I get it right, that WASM cannot work without JIT? Is it by design?

It is correct. Wasm only performant in JIT environments, especially for ML applications. The translation also requires SIMD for the same reason.

(In reply to Erik Nordin [:nordzilla] from comment #14)

Chas, one thing that I'm still uncertain of, is that you were reporting that you were just not seeing the Translations UI at all: the button wasn't showing, you didn't see the context menu item appear, etc.

When I run these steps, the Translations feature UI surfaces are available to me. They just fail when I attempt to use them.

Is it the same for you with these prefs? Were you able to figure out why the UI wasn't showing for you initially?

I've had both experiences. In my original issue, Bug 2026085, the UI wasn't showing for me at all. Once I fixed the issue, if it was working and I set both wasm jit to false without restarting, I got the UI but the translation failed.

And actually, I just had a recurrence of the behavior I reported in Bug 2026085, that upon launch of my 149 translation profile, despite javascript.options.wasm_optimizingjit being default/true, I wasn't getting the UI elements. So it's not about the upgrade from 148 to 149; something in 149 is spontaneously breaking translation when I have most jit turned off but not javascript.options.wasm_optimizingjit.

And the fix I discovered works to restore the function and the UI:

  1. Set all jit to default
  2. Relaunch
  3. Flip all jit booleans except javascript.options.wasm_optimizingjit and javascript.options.spectre.jit_to_cxx_calls
Flags: needinfo?(docorbit)
Attached image image.png —

(In reply to Chas Belov from comment #20)

(In reply to Erik Nordin [:nordzilla] from comment #14)

Chas, one thing that I'm still uncertain of, is that you were reporting that you were just not seeing the Translations UI at all: the button wasn't showing, you didn't see the context menu item appear, etc.

When I run these steps, the Translations feature UI surfaces are available to me. They just fail when I attempt to use them.

Is it the same for you with these prefs? Were you able to figure out why the UI wasn't showing for you initially?

I've had both experiences. In my original issue, Bug 2026085, the UI wasn't showing for me at all. Once I fixed the issue, if it was working and I set both wasm jit to false without restarting, I got the UI but the translation failed.

And actually, I just had a recurrence of the behavior I reported in Bug 2026085, that upon launch of my 149 translation profile, despite javascript.options.wasm_optimizingjit being default/true, I wasn't getting the UI elements. So it's not about the upgrade from 148 to 149; something in 149 is spontaneously breaking translation when I have most jit turned off but not javascript.options.wasm_optimizingjit.

And the fix I discovered works to restore the function and the UI:

  1. Set all jit to default
  2. Relaunch
  3. Flip all jit booleans except javascript.options.wasm_optimizingjit and javascript.options.spectre.jit_to_cxx_calls

Chas, I have a feeling that whatever Firefox 149 is doing in the case where you don't see the Translations UI at all, is causing getIsTranslationsEngineSupported() to return false, which ultimately means that your system is detecting that the required WASM SIMD operations are not supported in detectSimdSupport().

If you are able to reproduce this again, then, before you fix it, could you follow these steps to verify my suspicion?

  1. Open up the Developer Tools Cmd + I
  2. Click the triple-dot menu of the developer tools, at the top right, just next to the x.
  3. Click "Settings"
  4. Under "Advanced Settings" on the right side, ensure that "Enable browser chrome and add-on debugging toolboxes" is checked.
    4a. Note: This enables the command prompt in the Browser Console, which we are about to open.
  5. Open the Browser Console Cmd + Shift + J
  6. In the command prompt for the Browser Console, type TranslationsParent.getIsTranslationsEngineSupported() (see attached screenshot).
Flags: needinfo?(docorbit)

I can't guarantee this wasn't happening before today in 149 because I'm not in the habit of quitting and restarting my browser. At least as of today, the translation UI does not appear if I launch with the all-but-one-setting jit disabled. I can restore it using my fix steps.

And emphasizing this broken-after-working behavior is new to 149. I never had this problem (failure of translation UI as of restart) in 148.

Just to be sure, after re-enabling translation using my fix, I navigated to new pages and tried translating them and it works.

(In reply to Erik Nordin [:nordzilla] from comment #21)

If you are able to reproduce this again, then, before you fix it, could you follow these steps to verify my suspicion?

  1. Open up the Developer Tools Cmd + I
  2. Click the triple-dot menu of the developer tools, at the top right, just next to the x.
  3. Click "Settings"
  4. Under "Advanced Settings" on the right side, ensure that "Enable browser chrome and add-on debugging toolboxes" is checked.
    4a. Note: This enables the command prompt in the Browser Console, which we are about to open.
  5. Open the Browser Console Cmd + Shift + J
  6. In the command prompt for the Browser Console, type TranslationsParent.getIsTranslationsEngineSupported() (see attached screenshot).

Sorry, your request for more info crossed with my previous post. Here's your requested info.

Shows false upon restart, true after the fix. Noting that setting only appears to me to update upon restart.

If it is showing true, and I turn jit completely off without restarting, it continues to show true and offer the UI, but translation breaks. I can recover translation ability by turning either of the two WASM settings back on.

If it is showing false, and I enable jit without restarting, it continues to show false and not offer the UI.

(Nitpick alert: Open up Developer Tools is Opt + Cmd + I at least on my Mac.)

So it looks like having exactly one of the two WASM JIT settings off at launch results in TranslationsParent.getIsTranslationsEngineSupported() evaluating to false even though translation is capable of working.

(updated comment 25)

Since if TranslationsParent.getIsTranslationsEngineSupported() evaluates to true on launch, then I can enable, break, and reenable translation by toggling the WASM JIT settings verifies that the WASM JIT settings take effect immediately but TranslationsParent.getIsTranslationsEngineSupported() does not get updated to reflect that.

So it looks like having exactly one of the two WASM JIT settings off at launch incorrectly results in TranslationsParent.getIsTranslationsEngineSupported() evaluating to false even though translation is capable of working. I would consider that a bug.

And tried this on my virtual machine using 148.0.2, AI blocked, translation enabled.

With the following overrides:
javascript.options.baselinejit false
javascript.options.jithints false
javascript.options.main_process_disable_jit true
javascript.options.wasm_baselinejit false

Then restart.

TranslationsParent.getIsTranslationsEngineSupported() evaluates to true in 148.0.2.

Upgrade to 149 so I'm sure I'm using the same settings.

TranslationsParent.getIsTranslationsEngineSupported() evaluates to false in 149.

If it is showing true, and I turn jit completely off without restarting, it continues to show true and offer the UI, but translation breaks. I can recover translation ability by turning either of the two WASM settings back on.

If it is showing false, and I enable jit without restarting, it continues to show false and not offer the UI.

This experience makes sense because we cache the value after computing it the first time.

This code is 3 years old and has been pretty reliable in that time. However, it was written with the assumption that we are effectively checking for hardware support.

I think we assumed that the computed value of detectSimdSupport() wouldn't change during a browsing session: that if it were to fail, then it would be due to perhaps a lack of compatible CPU instructions or such, rather than something that could change at runtime due to pref changes.

This brings up some questions that I would like to get Ryan's perspective on:

1) Should we remove the cache from this check?

I profiled it over 1,000,000 iterations:

It seems like a pretty cheap function to call, with the (in)frequency that we need to call it. Perhaps our current cache is overly aggressive. I have a mild preference toward just running the detection every time, if it is deemed cheap enough of a call, rather than trying to map which prefs may affect this behavior, then clear our cache when those prefs change.

2) Is our current check achieving everything that it intends to?

I'm not a WASM-internals expert, so I just want to double check that detectSimdSupport() is achieving what we hope for it to achieve, and that it shouldn't be doing anything more or anything less.

Ah, understand why you might cache.

That the evaluation logic changed between 148 and 149 would be a separate issue.

Flags: needinfo?(docorbit)

And thinking about it, code changes reverting the regression between 148 and 149 back to 148 would need to coincide with or precede any switch from caching to every time. If the caching to every time switch happens first, then in won't be possible to get the translation UI with only one of the two WASM JIT settings at default even though Firefox would be capable of the translation.

*then it won't be possible

Ah this is a tricky one. Not sure if I know what's going on, but here's a guess.

Going off of comment 26:

I don't think this an issue with baseline vs ion being enabled (or at least can't figure out how it would be). They both support wasm simd.

'javascript.options.main_process_disable_jit' will disable all the JIT backends in the main process. Which will completely remove wasm support from the main process. There will be no 'WebAssembly' namespace in the global. Which will cause detectSimdSupport [1] to throw a ReferenceError and return false through the try-catch.

You can confirm if that pref is the issue by setting it to true, and then testing the various configs of the wasm compiler flags.

But why would this change from Fx148 to Fx149? Bug 1992206 is suspicious here and landed in Fx149, it changed when we read this preference to happen earlier. Maybe before that patch detectSimdSupport was able to run, but after that it started failing.

My understanding is that TranslationsParent runs in the main process, but the wasm execution is in a child process. Checking for wasm (and wasm simd) support in the parent process is going to be unreliable then. Is it possible to move the detection to the child process? If not, I'll try to think of a way to expose this information better.

[1] https://searchfox.org/firefox-main/rev/287c6cf323492ae0cc031e468c1d87f623413f50/toolkit/components/translations/actors/TranslationsParent.sys.mjs#4691-4722

Flags: needinfo?(rhunt)

Regarding comment 31:

'javascript.options.main_process_disable_jit' will disable all the JIT backends in the main process. Which will completely remove wasm support from the main process. There will be no 'WebAssembly' namespace in the global. Which will cause detectSimdSupport [1] to throw a ReferenceError and return false through the try-catch.

You can confirm if that pref is the issue by setting it to true, and then testing the various configs of the wasm compiler flags.

Confirming this test is giving incorrect information in 149.

  • Translations can happen as long as at least one of javascript.options.wasm_baselinejit or javascript.options.wasm_optimizingjit is set to true at the moment, even if javascript.options.main_process_disable_jit is false at the moment.

  • If both javascript.options.wasm_baselinejit and javascript.options.wasm_optimizingjit are false but TranslationsParent.getIsTranslationsEngineSupported() is true, Translation is offered but fails.

  • TranslationsParent.getIsTranslationsEngineSupported() appears to be based solely on the value of javascript.options.main_process_disable_jit at relaunch. That is, it evaluates to true on relaunch even if both javascript.options.wasm_baselinejit and javascript.options.wasm_optimizingjit are set to false at relaunch.

Continuing from comment 32:

  • 148.0.2 establishes that translation works even if javascript.options.main_process_disable_jit is false at relaunch

  • Therefore,

    • regardless of whether TranslationsParent.getIsTranslationsEngineSupported() is tested at relaunch or tested whenever translation service is requested,
    • it would correctly check that at least one of javascript.options.wasm_baselinejit and javascript.options.wasm_optimizingjit is true
    • and completely ignore the value of javascript.options.main_process_disable_jit

And refining that:

148.0.2 establishes that translation works even if javascript.options.main_process_disable_jit is false at relaunch and continues to be false throughout the session.

Sorry about the multiple posts.

And, alas, posting once more, for completeness.

Verified that setting javascript.options.wasm to false and restarting doesn't cause TranslationsParent.getIsTranslationsEngineSupported() to become false and doesn't impact translation from showing up in the UI or from working.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: