Firefox Community Forum

Hello Mozilla Support,

I'm experiencing an issue with how Firefox displays date and time input fields on websites when using Hebrew (Israel).

• • Environment:**

- Firefox version: 158.0 (64-bit) - Operating system: Windows - Browser interface language: Hebrew - Regional locale: he-IL

• • The problem:**

Date fields are displayed in the format YYYY.MM.DD (for example, 2026.10.14) instead of DD/MM/YYYY (14/10/2026).

Time fields also sometimes display their components in an incorrect order, apparently due to right-to-left (RTL) handling.

This issue occurs across multiple websites, including the standard HTML date input example on MDN, so it is not specific to any particular website.

• • Troubleshooting already performed:**

1. Verified Windows regional settings: Hebrew (Israel), short date format dd/MM/yyyy, and time format HH:mm. 2. Verified Firefox regional preferences show he-IL. 3. Tested intl.regional_prefs.use_os_locales with both true and false. 4. Tested intl.locale.requested with he,en-US, he-IL,en-US, and he-IL. 5. Changed the preferred website language order to prioritize he-IL. 6. Restarted Firefox after making changes.

Unfortunately, the date issue persists, and the time field display is also inconsistent.

• • Expected behavior:**

Date fields should display DD/MM/YYYY, and time fields should display HH:mm in the correct visual order, while keeping the Firefox interface in Hebrew.

Could you please confirm whether this is a known Firefox bug and whether there is a supported workaround or a planned fix?

Thank you.

I've followed all of Firefox's suggestions for translating web pages without success. (I have the latest version of Firefox.) No translation panel automatically opens when I visit a page in French. I have no translation icon in the tool bar to click, and "translate page" doesn't appear in any Firefox drop-down menus. No translation options appear when I right click on the web page. Any suggestions?

Environment: - Firefox 157.0.1 (64-bit) - Windows 11 (build 26100) - IME: Microsoft Pinyin (TSF)

Steps to reproduce: 1. Open any page with a text input (e.g. chat.deepseek.com). 2. Type quickly in Chinese Pinyin, e.g. "zuihou". 3. At some point during composition, the current composition ("zu") is committed as raw pinyin (with the apostrophe separator preserved), and the next key ("i") starts a new composition.

Expected behavior: - The composition should continue normally, and all keys should be consumed by the IME. - No raw pinyin string should ever be committed.

Actual behavior: - Firefox delivers the key event to the web page with keyCode 73 ("i") instead of keyCode 229 (Process), so the IME never receives it. - The IME's internal composition state stays at "zu" while the browser display has already moved on. - When the next key arrives, the IME commits the stale "zu" as raw pinyin and starts a new composition. - This results in the composition being split into two parts, with the first part committed as raw pinyin containing the "'" separator.

Additional context: - The problem occurs only in Firefox. In Edge (Chromium) on the same machine, typing the same sequence for several minutes never reproduces it. - It does not occur with every key; only certain keystrokes are affected, and it seems to require fast typing. - The issue is not caused by keyboard hardware, third-party software (AutoHotkey, yasb, PixPin, Intel drivers, MuMu), or key injection. A low-level keyboard hook log shows no injected events (inj=0 for all 204 keystrokes).

Log excerpt (from a JS composition probe injected into the page): [ime] 04:20:54.740 keydown key=Process isComposing=false keyCode=229 repeat=false [ime] 04:20:54.740 COMPOSITIONSTART data="" [ime] 04:20:54.741 compositionupdate data="z" [ime] 04:20:54.831 keydown key=Process isComposing=true keyCode=229 repeat=false [ime] 04:20:54.833 compositionupdate data="zu" [ime] 04:20:54.928 keydown key=i isComposing=true keyCode=73 repeat=false <-- key 73, not 229 [ime] 04:20:55.324 keydown key=Process isComposing=true keyCode=229 repeat=false [ime] 04:20:55.326 COMPOSITIONEND data="zu" <-- stale composition committed [ime] 04:20:55.327 COMPOSITIONSTART data="" [ime] 04:20:55.327 compositionupdate data="h"