Page MenuHomePhabricator

VisualEditor: Can't remove heading without header markup leaking to the rest of the page if it is the first element of the page
Closed, ResolvedPublic

Description

if an article starts with

Foo

Bar Baz Fizz Buzz

It is impossible to remove ==Foo== without having the paragraph take on the h2 markup


Version: unspecified
Severity: normal

Details

Reference
bz50254

Event Timeline

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

As a workaround, it is possible to convert the header to paragraph text and then delete it. That is no better though than deleting and then converting the changed text back to a paragraph.

Actually, this bug looks to be a subset of Bug 51829 is this best merged or that bug better split?

They definitely seem related, with the distinction that this but has the problem that there is no slug (am I using the lingo right) on the line above the first header if the header is the first element of the page. Merge however you feel is most useful.

It happens to me always, even if the heading is in the middle of the page.

This is a separate issue to bug 51829 (now bug 50100).

Change 85673 had a related patch set uploaded by Esanders:
Delete empty nodes instead of merging into them

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

The delete-when-empty-merge-otherwise behaviour implemented by the patch above is also used by OO/LO & Google docs.

Change 85673 merged by jenkins-bot:
Delete empty nodes instead of merging into them

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

Wikifram wrote:

Nice that this is solved, except that it isn't. I had already noted that at MediaWiki, it still blanks the header (but doesn't add nowiki). Tested today at enwiki, and sadly, even worse, again a nowiki was added inside the header instead of removing the empty header: [https://en.wikipedia.org/w/index.php?title=Robbers_Cave_State_Park&diff=575691345&oldid=558376701]

Has this patch ever worked anywhere? Diff?

You're confusing this with bug 50100.

Wikifram wrote:

(In reply to comment #10)

You're confusing this with bug 50100.

Not my mistake though, this was reported like this in the VisualEditor weekly update - 2013-09-26 (MW 1.22wmf19) by Jdforrester:

"Blanking the contents of a heading, pre-formatted block or other formatting block now deletes the block rather than leaving it empty, which is consistent with how OpenOffice and Google Docs behave (bug 50254)."

I noted that what the VE status report describes is ''not'' fixed, and followed the link number given in the VE status report. If this bug is about something else than what the VE status report described, then this is just one more in the already long list of things wrong with that status report (for which it is apparently "impossible" to write an update or correction in any way, shape or form).

Anyway, you still get the behaviour as described: Go to the first word you want to keep (after the initial header), and use backspace to remove the header: your next paragraph now becomes the header. Only when you first empty the header (leaving the line beneath it), and then go to the text and use backspace, is it possible to remove a starting header without converting the following text into a header. I wouldn't call this "solved", perhaps "somewhat improved" assuming that the latter possibility / workaround didn't work in the past. (I note that you only go to the start of the heading, and then select "downwards" instead of "sideways"; deleting the header like this works as well)

Note also that if yu eventually get rid of that header, it seems to be impossible to remove a first empty line from an article: [https://en.wikipedia.org/w/index.php?title=User%3AFram%2Fsandbox&diff=575703425&oldid=575703070]. Probably needs a different bug (or already exists), but not really optimal either.

Steady on, they're similar bugs and easy to confuse.

The case you describe at the end does sound like a separate bug.

Wikifram wrote:

(ec) Yeah, I'm a bit frustrated by the number of errors in that status update, and the apparent lack of possibilities to correct these (even as an addendum or some such) and lack of care about this among the people responsible for this. Not your fault though. Thanks for filing that bug.