VisualEditor: FocusableNodes (e.g. Infoboxes) are too easy to accidentally delete, especially when floated
Closed, ResolvedPublic

Description

Erik Moeller: "
I agree with previous commenters that this is likely to be at the cause of a
lot of the accidental infobox deletions and such. I understand it's a tricky
issue, but the current behavior is extremely confusing from the user's point of
view, so we need to look at some viable solutions.

Recapping the simple case: User is on what they perceive to be an unnecessary
newline, presses delete to make the visual layout match the expected layout. A
separate object (in the case of the infobox, right-aligned on the other side of
the screen) suddenly disappears. This is very surprising and counter-intuitive
behavior.

Why don't we just suppress the delete key when pressing it would delete the
object the slug is associated with? In some alternative editors like Google
Docs, it is actually not possible to nuke the entire document by just pressing
down the delete key at the top of the page -- it will stop before certain
objects. I've never had any problems as a result.

That seems like the simplest solution to me and does not require a redesign of
the slugs.
"


Version: unspecified
Severity: major

bzimport set Reference to bz55336.
Esanders created this task.Via LegacyOct 5 2013, 9:01 AM
Esanders added a comment.Via ConduitOct 5 2013, 9:03 AM

I agree, although I would say instead of suppressing the delete/backspace key, it should cause the adjacent FocusableNode (e.g. Infobox) to become focused, so that a second keypress actually deletes it. This shouldn't be too difficult to achieve.

gerritbot added a comment.Via ConduitOct 5 2013, 10:31 AM

Change 87666 had a related patch set uploaded by Esanders:
Prevent deletion of FocusableNodes from a collapsed selection

https://gerrit.wikimedia.org/r/87666

Eloquence added a comment.Via ConduitOct 9 2013, 2:47 AM

Will this also cause citations and similar inline nodes to be first selected, rather than deleted, when you press backspace or delete next to them? I'm not saying that would necessarily be wrong behavior (I think it could actually be helpful), but just wanted to clarify.

Esanders added a comment.Via ConduitOct 9 2013, 5:37 AM

Yes, anything you can select with a single click (focusable). We could restrict it to non-inline elements but I think it's useful for inline too.

gerritbot added a comment.Via ConduitOct 9 2013, 5:22 PM

Change 87666 merged by jenkins-bot:
Prevent deletion of FocusableNodes from a collapsed selection

https://gerrit.wikimedia.org/r/87666

Eloquence added a comment.Via ConduitOct 9 2013, 6:40 PM

I'm confirming on http://en.wikipedia.beta.wmflabs.org/wiki/Greg_and_Karen_DeSanto as a test case that this is working as intended. I would encourage others who care about this issue to try as well (note you'll need to login and enable VE, just as you do on en.wp, since Beta has the same config).

One small UX issue I'm noticing is that you can't consistently cursor away from the focusable nodes, which is somewhat exacerbated now that they're more frequently selected as you delete/backspace through content. I suggest tracking that as a separate bug, if it isn't one already.

AdHuikeshoven added a comment.Via ConduitJul 11 2014, 9:31 PM

On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on "white lines" as a blocking issue for turning VE on as default.
On top of pages like:

as well as on other places on the page "white lines" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue.

Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.

This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.

(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)

How can I help to resolve this 'bug'? I will also copy to bug 55336.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.