The Safari Feature Flag “Correct key event ordering with composition events” changes the ordering of keyboard and composition events as expected in Safari, but the same setting does not appear to affect macOS Web Apps created using “Add to Dock”. This is observable with an IME where Return/Enter is used to commit an active composition, such as the built-in Traditional Chinese – Zhuyin input source. Steps to reproduce 1. On macOS 26, open Safari 26. 2. In Safari Settings → Advanced → Feature Flags, enable: “Correct key event ordering with composition events”. 3. Relaunch Safari. 4. Open a page which logs keydown, keyup, compositionstart, compositionupdate, and compositionend events. 5. Switch the macOS input source to a Traditional Chinese one, for instance, Bopomofo (Zhuyin). 6. Start composing text and press Return to commit a candidate. 7. Observe that Safari uses the corrected composition/key event ordering when the Feature Flag is enabled. 8. Add the same website to the Dock as a macOS Web App. 9. Quit and relaunch the Web App after enabling the Feature Flag. 10. Repeat the same IME input and Return-to-commit operation in the Web App. Actual result In Safari, enabling “Correct key event ordering with composition events” changes the event ordering to the corrected behavior. In the macOS Web App, the legacy event ordering remains in effect, as if InputMethodUsesCorrectKeyEventOrder were disabled. In particular, when Return is used to commit an IME candidate, the Web App can still dispatch compositionend before the corresponding keydown event. Consequently, the Enter keydown is exposed to page script with isComposing === false. This is the behavior previously described in WebKit Bug 165004 and addressed by Bug 311717. The difference can be reproduced on the same Mac, with the same website and the same input method: Safari + Feature Flag enabled → corrected key/composition event ordering macOS Web App + same Safari Feature Flag enabled → legacy key/composition event ordering Fully quitting and relaunching the Web App after changing the Feature Flag does not cause the setting to take effect. Expected result A macOS Web App should use the same value of the “Correct key event ordering with composition events” Feature Flag as Safari, or there should otherwise be a way to enable the corrected WebKit behavior for Web Apps. At minimum, Safari and a Web App created from the same website should not unexpectedly use different composition/key event models solely because the page is running as a Web App. Impact This difference has a visible effect on websites which use Enter to submit a message or activate an action. When the legacy event ordering is used, pressing Return to commit an IME candidate can also be interpreted by page JavaScript as an ordinary Enter keypress because KeyboardEvent.isComposing is already false. This can cause partially composed Chinese text to be submitted unintentionally. The issue affects Web Apps for sites whose Enter-key handlers rely on the standardized isComposing state. The same sites behave correctly in Safari when the Feature Flag is enabled. Related bugs Bug 311717 — Correct composition/key event ordering implementation https://bugs.webkit.org/show_bug.cgi?id=311717 Bug 165004 — The event order of keydown/keyup events and composition events are wrong on macOS https://bugs.webkit.org/show_bug.cgi?id=165004 Bug 272226 — [macOS Only] The “Prefer Page Rendering Updates near 60fps” Feature Flag does not affect Web Apps https://bugs.webkit.org/show_bug.cgi?id=272226 Bug 272226 appears related because it documents another Safari Feature Flag whose value is applied in Safari but not in macOS Web Apps.