[BUG] Field names in the editor are selectable

anki_9Bbcn7IaSL

As can be seen in the gif, you can select the white space to the left of the field names in the note editor. You can also drag the field name and paste into the field just like you would do with an image on any webpage:

anki_Q56IJ9NwEg

If you think this is a bug, be prepared for the svelte page. It’ll have everything selectable if we don’t specify otherwise. There is a discussion on github about this on one of my open PRs, check that.

In the current deck options, you can select text, but you can’t paste it and make a mess as shown in the second gif. Also, the current editor doesn’t allow selecting the field name usually; you have to do some tricks with your mouse to select the empty space to the left of it.

Well, let’s hope this changes with the new screen.

1 Like

What new screen? It already is in svelte, so I’m assuming I missed plans regarding a redesign.

If not (even though I dislike having text not selectable here), I opened a PR to make the text and the icon unselectable:

1 Like

The field names are not selectable (they can be copied with some effort like in gif 2). If you feel like it, you can make them selectable (just with stripped formatting and without the space and the arrow).

I know. I meant to say that I prefer text elements to be always selectable. I know sorata disagrees.

But in this case, I do not really mind, as the field names could be copied by either using the dev console, or by opening the edit fields dialog.

The proposed fix in the PR above makes the entire container unselectable, which does include the text. I didn’t try it, but I assume I’d have to put the icon into it’s own container for that to work. Not sure if it’s worth it, considering the field names can be copied as I outlined above (and unlike things like the preferences, copying the field names probably isn’t that common, if used at all)

1 Like

Maybe, on the contrary, we should make it possible to select them? Not everyone is that technically advanced.

They can just type them out…

1 Like

Only if it’s in my native language or in English.

They can take a screenshot and go to their favorite ocr website…

Does not work equally well for different languages.

I’m not against the text being selectable, I would like it to be (in a reasonable fashion). It’s up to the devs to decide if it’s worth their time.

I’m not a dev, just a novice programmer that likes to open PRs sometimes.

But I can try and check if this behavior from OP can be fixed (with my limited skillset), while making the text selectable.

I may need a few days though, as my schedule is quite tight right now. Meaning if it’s not something I can fix in the break times between schedules, I might have to close the PR (or we stay with the current bug fix, since the text wasn’t selectable in the first place).

1 Like

Can you just verify that I understood this correctly?

  1. The text of those labels should be selectable.
  2. Selecting multiple things (e.g. text and buttons), then dragging it into a richtext field pastes those buttons inside said field.

Regarding #1: In the linked PR, I opened a suggestion to make this work.

Regarding #2: I think this can be prevented by sanitizing all non-text elements on paste. Though I am wondering: considering we’re talking about a richtext editor, isn’t it somewhat expected behavior that the buttons appear there after dragging them into the richtext editor? The editor should display the html as an actual entity (e.g. buttons) after all. That’s what richttext editors do.

I couldn’t figure out how to make the ui elements unselectable, e.g. if the user is doing Ctrl+A. Apparently, the buttons still are part of the selection, just not highlighted.

  1. Yes. e.g. ā€œFrontā€ should be selectable.
  2. The buttons should not be selectable. Then we won’t have to worry about expected behavior and richtext editors.
1 Like

They aren’t really selectable. The behavior with the current state of my PR is the same as the way it currently works in Anki.

I’m not sure how to properly describe it. If I remove selection from everything on the Add dialog, including text, then the problem is gone. But once text can be selected, the DOM (i guess) automatically adds other html entities to the selection, if they are in range – which results in buttons being pasteable as you showed in your gif.

I don’t know how to prevent this though, if text selection is prefered. Maybe someone here can help or has an idea?