Closed Bug 1779913 Opened 2 years ago Closed 2 years ago

TONS of non-standard text selection on macOS

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Version:
Firefox 102
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kasperkh.kh, Unassigned)

References

Details

Attachments

(1 file)

Firefox cursor blink.mp4
486.86 KB, video/mp4
Details

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

Steps to reproduce:

Firefox has far too much non-standard text selection/cursor movement behavior that makes Firefox feel really weird, unnatural and out-of-place. Please do something to follow what the OS standard instead of creating an imperfect imitation. The current approach of guessing the correct behavior does not seem to work.

Here's what I've found so far, with my limited usage:

  • Shift+up does not work in some places
  • Shift+right selects to and includes punctuation
  • Shift+right selecting a word wrapped in double quotes selects the whole word
  • Shift+right selection treats single quotes as punctuation rather than part of a word
  • Double-clicking a word + shift-selecting does not select whole words
  • Right-clicking a word does not select the word
  • If there's a wrapped line, both the space and newline character are individually selected, meaning there's one more selection than there should be
  • The cursor blinks when cursor moves

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.

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

Trying a more dedicated component. Please feel free to reassign if this isn't the right one.

Component: Widget: Cocoa → Layout: Text and Fonts

(In reply to Kasper from comment #0)

  • Shift+up does not work in some places

Please give a specific example of where it doesn't work -- in a few quick tests, it seems to work for me, but I may not be looking at the right places.

  • Shift+right selects to and includes punctuation

I assume you mean shift+opt+right, to move forward by words. Yes, it appears to include trailing punctuation characters, whereas Safari stops before them. So that's a discrepancy.

  • Shift+right selecting a word wrapped in double quotes selects the whole word

(Again, shift+opt+right?) So if we have "word" and the cursor is before the opening double-quote, Firefox selects the entire word including both the opening and closing quotes, whereas Safari stops before the close-quote. So in that case, Firefox's behavior seems better (the selection ends up complete/balanced). But if the cursor starts out after the opening double-quote, the Safari behavior of stopping before the closing one is preferable.

  • Shift+right selection treats single quotes as punctuation rather than part of a word

Sometimes they are 'punctuation' and sometimes they aren't. I suppose a better heuristic may be to treat them as part of the word if they're both preceded and followed by letters, and not otherwise. Though tricky cases like "the girls' toys" will still be a problem.

  • Double-clicking a word + shift-selecting does not select whole words

This seems to be the same as Safari's behavior. (TextEdit, on the other hand, selects whole words when extending a double-click selection using shift-select. So even Apple's own applications are not entirely consistent here.)

  • Right-clicking a word does not select the word

Interesting; as I understand it, the purpose of right-click is to open a contextual (popup) menu. But yes, I see that some other applications (including Safari) will first select the word under the cursor (as if double-clicked) before popping up the menu.

  • If there's a wrapped line, both the space and newline character are individually selected, meaning there's one more selection than there should be

Yes, that does seem odd.

  • The cursor blinks when cursor moves

I'm not sure I understand this. It looks to me like the cursor remains visible while moving, and then blinks once it has come to a stop; and other applications behave the same. What am I missing here?

Component: Layout: Text and Fonts → DOM: Selection

The main point of this report isn't really to get individual fixes for each incorrect behavior, but more to encourage actual native behavior to be used so that these issues don't pop up.

But as for the specifics you mention:

(In reply to Jonathan Kew (:jfkthame) from comment #3)

  • Shift+up does not work in some places
    Please give a specific example of where it doesn't work -- in a few quick tests, it seems to work for me, but I may not be looking at the right places.

The address bar is the place I noticed this.

  • Shift+right selects to and includes punctuation

I assume you mean shift+opt+right, to move forward by words. Yes, it appears to include trailing punctuation characters, whereas Safari stops before them. So that's a discrepancy.

Yes correct, I mean shift+option+right

  • Shift+right selecting a word wrapped in double quotes selects the whole word

(Again, shift+opt+right?) So if we have "word" and the cursor is before the opening double-quote, Firefox selects the entire word including both the opening and closing quotes, whereas Safari stops before the close-quote. So in that case, Firefox's behavior seems better (the selection ends up complete/balanced). But if the cursor starts out after the opening double-quote, the Safari behavior of stopping before the closing one is preferable.

Yes, shift+opt+right in this case too. Sure, you could say Firefox's behavior seems better (I disagree personally), but that doesn't mean it's good to do it differently when every other app follows a standard. I'd rather not end up with every app having a different opinionated text selection behavior.

  • Shift+right selection treats single quotes as punctuation rather than part of a word

Sometimes they are 'punctuation' and sometimes they aren't. I suppose a better heuristic may be to treat them as part of the word if they're both preceded and followed by letters, and not otherwise. Though tricky cases like "the girls' toys" will still be a problem.

It would be best to use native behavior

  • Double-clicking a word + shift-selecting does not select whole words

This seems to be the same as Safari's behavior. (TextEdit, on the other hand, selects whole words when extending a double-click selection using shift-select. So even Apple's own applications are not entirely consistent here.)

For me, Safari follows the standard behavior. To clarify: Double-click a word, then shift-click another word.

  • Right-clicking a word does not select the word

Interesting; as I understand it, the purpose of right-click is to open a contextual (popup) menu. But yes, I see that some other applications (including Safari) will first select the word under the cursor (as if double-clicked) before popping up the menu.

Right-clicking text on macOS should select the text. This also counts for drag-selecting in 2d areas like the desktop and Finder's icon view.

  • The cursor blinks when cursor moves

I'm not sure I understand this. It looks to me like the cursor remains visible while moving, and then blinks once it has come to a stop; and other applications behave the same. What am I missing here?

Here's a screen recording demonstrating it, with Firefox being on the right: https://youtu.be/anAZWAZXKm8

Comment on attachment 9285951 [details]
Firefox cursor blink.mp4

Attached the cursor blinking recording here as well

Found another one:

  • Write "one two", double click the word "one", then press delete. The space between the words is not deleted in Firefox

(In reply to Kasper from comment #4)

  • The cursor blinks when cursor moves

I'm not sure I understand this. It looks to me like the cursor remains visible while moving, and then blinks once it has come to a stop; and other applications behave the same. What am I missing here?

Here's a screen recording demonstrating it, with Firefox being on the right: https://youtu.be/anAZWAZXKm8

Ah - I think what you're seeing here is an interaction between the cursor-blink rate and the key-repeat rate, and this appears to be slightly different e.g. in Safari. As I understand it, the cursor is always shown immediately when it moves, but if the key-repeat rate is fairly slow, then it may have time to blink off just before the next repeat fires and it moves again.

If you set the key-repeat rate one step slower in the Keyboard Preferences, the effect looks very similar in Safari: the cursor blinks off after each move, then reappears when it moves again. And conversely, if you set it a step faster, then the cursor in Firefox moves without blinking as the repeat events fire just before it would blink off, and reset the blink time.

(I didn't see the effect at all when I tried previously because I normally have a fast key-repeat setting on my system.)

(In reply to Jonathan Kew [:jfkthame] from comment #8)

(In reply to Kasper from comment #4)

  • The cursor blinks when cursor moves

I'm not sure I understand this. It looks to me like the cursor remains visible while moving, and then blinks once it has come to a stop; and other applications behave the same. What am I missing here?

Here's a screen recording demonstrating it, with Firefox being on the right: https://youtu.be/anAZWAZXKm8

Ah - I think what you're seeing here is an interaction between the cursor-blink rate and the key-repeat rate, and this appears to be slightly different e.g. in Safari. As I understand it, the cursor is always shown immediately when it moves, but if the key-repeat rate is fairly slow, then it may have time to blink off just before the next repeat fires and it moves again.

If you set the key-repeat rate one step slower in the Keyboard Preferences, the effect looks very similar in Safari: the cursor blinks off after each move, then reappears when it moves again. And conversely, if you set it a step faster, then the cursor in Firefox moves without blinking as the repeat events fire just before it would blink off, and reset the blink time.

(I didn't see the effect at all when I tried previously because I normally have a fast key-repeat setting on my system.)

In the video, I manually pressed the arrow keys, so that doesn't seem like the problem. I also have the key repeat setting to the maximum that macOS System Preferences allows. The key repeat setting doesn't seem to affect the cursor blinking as far as I can tell. Either way, this seems to be non-native behavior from Firefox since no other app acts like that.

The severity field is not set for this bug.
:edgar, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(echen)

(In reply to Kasper from comment #4)

  • Shift+up does not work in some places
    Please give a specific example of where it doesn't work -- in a few quick tests, it seems to work for me, but I may not be looking at the right places.

The address bar is the place I noticed this.

There is a bug which is filed for that, see bug 1713675.

See Also: → 1713675

(In reply to Kasper from comment #4)

(In reply to Jonathan Kew (:jfkthame) from comment #3)

  • Shift+right selects to and includes punctuation

I assume you mean shift+opt+right, to move forward by words. Yes, it appears to include trailing punctuation characters, whereas Safari stops before them. So that's a discrepancy.

Yes correct, I mean shift+option+right

  • Shift+right selecting a word wrapped in double quotes selects the whole word

(Again, shift+opt+right?) So if we have "word" and the cursor is before the opening double-quote, Firefox selects the entire word including both the opening and closing quotes, whereas Safari stops before the close-quote. So in that case, Firefox's behavior seems better (the selection ends up complete/balanced). But if the cursor starts out after the opening double-quote, the Safari behavior of stopping before the closing one is preferable.

Yes, shift+opt+right in this case too. Sure, you could say Firefox's behavior seems better (I disagree personally), but that doesn't mean it's good to do it differently when every other app follows a standard. I'd rather not end up with every app having a different opinionated text selection behavior.

There is a bug for shift+option+right case, see bug 1682276.

See Also: → 1682276

(In reply to Kasper from comment #4)

  • Right-clicking a word does not select the word

Interesting; as I understand it, the purpose of right-click is to open a contextual (popup) menu. But yes, I see that some other applications (including Safari) will first select the word under the cursor (as if double-clicked) before popping up the menu.

Right-clicking text on macOS should select the text. This also counts for drag-selecting in 2d areas like the desktop and Finder's icon view.

Bug 1184698 is filed for right-clicking a word on Mac.

See Also: → 1184698

(In reply to Kasper from comment #4)

  • Double-clicking a word + shift-selecting does not select whole words

This seems to be the same as Safari's behavior. (TextEdit, on the other hand, selects whole words when extending a double-click selection using shift-select. So even Apple's own applications are not entirely consistent here.)

For me, Safari follows the standard behavior. To clarify: Double-click a word, then shift-click another word.

I did not fine any existing bug for this, so I filed bug 1782922.

See Also: → 1782922

(In reply to Kasper from comment #4)

  • The cursor blinks when cursor moves

I'm not sure I understand this. It looks to me like the cursor remains visible while moving, and then blinks once it has come to a stop; and other applications behave the same. What am I missing here?

Here's a screen recording demonstrating it, with Firefox being on the right: https://youtu.be/anAZWAZXKm8

This seems like the same as bug 1600303.

See Also: → 1600303
See Also: → 1783641

(In reply to Kasper from comment #7)

Found another one:

  • Write "one two", double click the word "one", then press delete. The space between the words is not deleted in Firefox

Doesn't found existing bug, filed bug 1783641 for this.

(In reply to Kasper from comment #0)

  • If there's a wrapped line, both the space and newline character are individually selected, meaning there's one more selection than there should be

I am not quite sure what is this issue about, could you elaborate? Thanks!

Flags: needinfo?(echen) → needinfo?(kasperkh.kh)

(In reply to Edgar Chen [:edgar] from comment #17)

(In reply to Kasper from comment #0)

  • If there's a wrapped line, both the space and newline character are individually selected, meaning there's one more selection than there should be

I am not quite sure what is this issue about, could you elaborate? Thanks!

First of all I wanna stress again that this issue isn't really meant for fixing each individual issue, it's to make Firefox use actual native text (like the switch to native context menus) so that these kinds of issues are impossible and don't pop up in the future.

That specific one is about Shift+RightArrow selecting more characters than it should

Flags: needinfo?(kasperkh.kh)

(In reply to Kasper from comment #18)

First of all I wanna stress again that this issue isn't really meant for fixing each individual issue, it's to make Firefox use actual native text (like the switch to native context menus) so that these kinds of issues are impossible and don't pop up in the future.

We need to edit HTML too, so it's not clear how such thing would work.

Using native text fields is unfortunately not an option for a browser engine. You will find that Webkit had to painstakingly reimplements all of this behavior from scratch, too: https://searchfox.org/wubkat/source/Source/WebCore/editing/FrameSelection.cpp#949

(In reply to Kasper from comment #18)

That specific one is about Shift+RightArrow selecting more characters than it should

I think this is the same one as bug 347494.

Yes, we have to implement all these behavior in browser engine. Since all issues have individual bug to track, I am going to close this as WONTFIX. Feel free to file a new bug if you encounter other issues. Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Resolution: FIXED → WONTFIX

(In reply to Markus Stange [:mstange] from comment #20)

Using native text fields is unfortunately not an option for a browser engine. You will find that Webkit had to painstakingly reimplements all of this behavior from scratch, too: https://searchfox.org/wubkat/source/Source/WebCore/editing/FrameSelection.cpp#949

Ah I see, thanks for explaining

I can use Firefox (unlike Safari) precisely because it includes accessibility options (like stopping blinding cursors) that aren't available at the system level.

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

Attachment

General

Creator:
Created:
Updated:
Size: