Last modified: 2014-07-11 21:31:20 UTC
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. "
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: * https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit * https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit * https://nl.wikipedia.org/wiki/Rijn?veaction=edit * https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit * https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit 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.
