Page MenuHomePhabricator

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

Details

Reference
bz55336

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:35 AM
bzimport set Reference to bz55336.

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.

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

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

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.

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.

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

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

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.

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.