Page MenuHomePhabricator

Incorrect edit summary preloading when editing section 0
Closed, DeclinedPublic

Description

Author: jelle.zijlstra

Description:
When editing section 0, the section in the edit summary automatically gets filled in when the section contains some sort of header code. Example (thanks to Anomie): http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=462178059&action=edit&section=0 .

This bug is apparently in the MediaWiki core. I think it can be fixed by adding a check for section 0 at line 1720 of includes/EditPage.php (change line 1720 to "if ( $this->section != '' && $this->section != 'new' && $this->section != '0' ) {". Since section 0 is the lead of the article, it'll never have a legitimate section heading, so this addition should not cause any problems.


Version: unspecified
Severity: normal

Details

Reference
bz32617
TitleReferenceAuthorSource BranchDest Branch
Add missing default value for disallowEmptyDocumentation (true)repos/ci-tools/banana-checker!7esandersempty-doc-fixmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:08 AM
bzimport set Reference to bz32617.

EN.WP.ST47 wrote:

Patch that changes the regex mode.

The problem isn't necessarily only present in section zero - rather whenever there is a malformed section link. Since we're editing a section, we only care about section headers at the beginning of the current text we're editing, so I've changed the regex that looks for them from /m to /s, which causes the ^ to match the beginning of the string and not simply the beginning of the line. Patch is attached, causes no new unit test failures.

Attached:

jelle.zijlstra wrote:

I don't think there will ever be a problem with any other section than section 0, because the first text in a section other than section 0 will always be the (correct) section header. Example: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Wikipedia:Sandbox&action=edit&oldid=462411168&section=1
Your patch would fail on an article that starts with an invalid section header, like "== foo == a".

The regex change feels wrong to me; using dotall mode means that it may actually extend beyond finding your section title down into the text somewhere, if "=" or "==" or "===" etc appears somewhere later down in the text.

Perhaps remove both 'm' and 's' modifiers: make it match on the first line only, and don't attempt to go beyond the first line.

Adding need-unittest keyword; this is a great candidate for lifting the text extraction out to a function and running some test text through it.

r105379 extracts the function out and adds test cases.

I can confirm that applying the patch posted above fixes the "bogus section header in section 0" case, but creates the problem I describe in comment 3 when you have that happen in another section which has its own header with a matching "=" count.

r105380 adds a modified fix which passes my test cases.

This removes both 'm' and 's' modifiers, and checks to make sure we're at the end of the line. It's possible that this breaks in some other legit cases.... but I think it's right in theory. :)

In theory. :P

jelle.zijlstra wrote:

That won't work; you can have comments at the end of a line containing a section header, after all. What's wrong with the suggestion I gave?

Durrrr, how'd I skip over that? :P Yes, that should do the job, will poke at it later.

sumanah wrote:

Is this problem still reproducible? I don't think I've run into it.

Patch superseded by code change in comment 6, removing keyword.