1973393 - If there is text in another language (for example, English) next to Korean characters, it is also selected after double-clicking LMB on it (in macOS)

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, enhancement)

Description

[5silentrain]

Attachment: Screenshot 2025-06-22 at 16.34.40.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

1. Open this video on YouTube: https://www.youtube.com/watch?v=5B_Og0Prg_E
2. Hover your mouse over a pair of Korean characters at the beginning of the video title (희진DJ) and left-click over them

Actual results:

Not only these Korean characters are selected, but also the English abbreviation "DJ".

Expected results:

See how Chrome and Safari behave in this case. You can notice that after performing the above steps in these web browsers, only Korean characters are selected. I understand perfectly well that for the vast majority of users this does not matter at all, but the devil, as we know, is in the details. In general, Firefox is the only web browser that has so many problems with text selection under macOS, and this is just one of them.

Comment 1

[5silentrain]

Here's another example: https://www.youtube.com/watch?v=mogzyt6kLAA

Here's the part of the text from the video title that is incorrectly selected by double-clicking the left mouse button: MBC250621방송

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Stephen A Pohl [:spohl]]

I'm not sure if this is the right component. Please feel free to forward if necessary.

Comment 4

[Jonathan Kew [:jfkthame]]

This isn't specific to macOS, it behaves the same on other platforms.

AFAICS this is the expected behavior of the ICU4X word-segmenter, which in turn is based on UAX#29. The default algorithm there does not include any rule that would introduce a word boundary between Hangul characters and adjacent Latin letters or numerals.

However, the notes following the default word-segmentation rules in UAX#29 then mention:

Normally word breaking does not require breaking between different scripts. However, adding that capability may be useful in combination with other extensions of word segmentation...

and go on to give a mixed Korean/Latin-script example.

Seems like this would be a good extension to implement, either in the segmenter itself or in the layout code that sets up word boundary flags (see ClusterIterator in nsTextFrame.cpp).

Comment 5

[5silentrain]

I still don't understand, should I expect this to be fixed in future versions of Firefox? 🤔

I checked the behavior in the built-in macOS text editor, which is called TextEdit, by pasting this text there:
[4K] 250621 희진DJ - 'PTT (Paint The Town)' 직캠 | Club Icarus in Seoul
ARTMS (아르테미스) - Icarus | Show! MusicCore | MBC250621방송

TextEdit behaves similarly to Chrome and Safari 👌 That is, only Firefox behaves differently 🤷‍♂️

Comment 6

[Jonathan Kew [:jfkthame]]

Yes, I think it's likely we'll try to improve this; it seems like a worthwhile improvement and may not be terribly difficult to implement.

(Just for the record, I'll note that Google Docs behaves like Firefox here: double-clicking anywhere in "희진DJ" or "MBC250621방송" selects the entire range containing both the Korean and Latin characters. So we're not alone! But still, I'd be in favor of changing this behavior.)

Comment 7

[5silentrain]

Yes, I think it's likely we'll try to improve this; it seems like a worthwhile improvement and may not be terribly difficult to implement.

Great! 🥳 Thank you very much 🤝 It means I didn't waste my time filing this bug report.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1973393 - Treat transition between Hangul and non-Hangul chars as a word boundary. r=#layout

This is not part of the default word-segmentation rules in UAX#29 that are
implemented by the ICU4X segmenter, but is suggested as an extension in a
note following the rules, and corresponds with behavior seen in both Chrome
and Safari (as well as in some editors/word processors). As such, I think
it makes sense to do this.

The included WPT fails without the patch, and passes with it. (It should
also pass in both Safari and Chrome, afaict.)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cb527a5f295c
https://hg.mozilla.org/integration/autoland/rev/c0913a503322
Treat transition between Hangul and non-Hangul chars as a word boundary. r=layout-reviewers,emilio

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/53371 for changes under testing/web-platform/tests

Comment 11

[amarc]

https://hg.mozilla.org/mozilla-central/rev/c0913a503322

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 13

[5silentrain]

Wow! I never thought you would close my bug report so quickly, solving the problem 👀 👏
Thank you!
I wish developers would pay more attention to such little things, like Apple does.