Page MenuHomePhabricator

Return to the correct section after section edit for a heading that exists multiple times
Open, LowestPublic

Description

Author: timwi

Description:
BUG MIGRATED FROM SOURCEFORGE
https://sourceforge.net/p/wikipedia/bugs/790/
Originally submitted by Nobody/Anonymous - nobody 2004-05-30 11:51

If there are two sections with the same name, e.g:
"X", "Examples" (of X)
"Y", "Examples" (of Y)
and you edit "Examples" (of Y), after saving the page
you will be returned to "Examples" (of X)

  • Additional comments ------------------------

Date: 2004-08-09 07:13
Sender: SF user vibber

Lowering priority. It's kind of annoying, but rare
and non-destructive.


Version: MediaWiki 1.23.0
See Also:
T62396: Echo doesn't link to the correct section if there are duplicate section headings
T4831: Links in autogenerated summary in page histories may point to wrong section or to nowhere

Details

Reference
bz111

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:45 PM
bzimport set Reference to bz111.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

*** Bug 118 has been marked as a duplicate of this bug. ***

  • Bug 2022 has been marked as a duplicate of this bug. ***
  • Bug 2404 has been marked as a duplicate of this bug. ***

gangleri wrote:

renamed to "Return to page after edit of section *(where section name occurs
multiple times)*"

last note in bug 2831 coment 0 releates to this

Regards Reinhardt [[user:gangleri]]

  • Bug 3196 has been marked as a duplicate of this bug. ***

robchur wrote:

*** Bug 5395 has been marked as a duplicate of this bug. ***

ezyang wrote:

A possible fix would be to keep an lookup array of used id/names and keep on
adding to it as you parse the wikitext. If there's a collision, append a number,
and try again (if another collision, increment the number). Not sure how this
would affect the rest though, and there would be no way of figuring out the
anchor name from an isolated section.

stux wrote:

I beleive you may have to simply re-parse the entire file until we get to the
section in question and just count the number of ocurrances where we see the
same title (this can be done before the edit screen shows up, special care must
be taken during edit conflicts). The section headings following the one we edit
really do not affect the nomenclature of the emerging link. HOWEVER, I do see a
problem with changing heading names breaking external links to specific
sections. See this test page for an example:
http://test.wikipedia.org/w/index.php?title=User:Stux/sectionTest1&action=history

But that belongs at a different bug and I think that duplicate headings should
be handled differently (i.e. #Section_Subsection_SubSubsection).

wikimedia wrote:

While in the main namespace, #Section_Subsection_SubSubsection may both be logical and solve this problem, in talk pages it is not uncommon for there to be more than one heading with the same name on the same level. This would still not be addressed, and I would assume that the numbering as currently used in anchors would be best.

I believe the section IDs can be obtained from the parser output structure these days, and we do a parse on save. Should be possible to grab the proper formulation of the section name for the redirect.

This bug is related to bug 18700 ("Link to section does not work in edit summaries in case of multiple sections with the same name").

  • Bug 18700 has been marked as a duplicate of this bug. ***
  • Bug 15847 has been marked as a duplicate of this bug. ***
  • Bug 21275 has been marked as a duplicate of this bug. ***
  • Bug 34225 has been marked as a duplicate of this bug. ***

Partial fix in Gerrit changeset 55508.

*** Bug 60463 has been marked as a duplicate of this bug. ***

Keywords for finding this bug again: duplicate section header, duplicate section heading, same section headers, same section headings, post-save redirect

Still reproducible today, both with "Edit source" and "Edit links".

Filed almost 10 years ago, with 9 duplicates (the last one less than 4 months old), 20 users CCed, 10 votes, and a -1 changeset that went through 12 revisions last Summer, I think this is the oldest relevant bug that still bothers people.

Any ideas to solve it? Dan, this might be a good candidate in your list.

PS: adding "design" keyword because this is a UX problem.

Quim, while I agree it is a bad user experience, the fix seems to be a purely engeineering one. If this is 10 years old hopefully Parsoid offers a solution now.

(In reply to Quim Gil from comment #19)

Any ideas to solve it? Dan, this might be a good candidate in your list.

My list (context: https://www.mediawiki.org/wiki/Platform_product_microtasks) is for problems where I can clearly define the engineering solution. In this case, I can only think of one easy solution, and it's a bit of a ridiculous one, so it's better that I leave it off the list.

(In reply to Jared Zimmerman (WMF) from comment #20)

Quim, while I agree it is a bad user experience, the fix seems to be a
purely engeineering one. If this is 10 years old hopefully Parsoid offers a
solution now.

Sure. We can leave the keyword off.

Alright, then this means that nobody is planning to work on this right now. Setting priority accordingly.

The fact is that a MediaWiki page with several sections with the same label will have a different anchor for each. See "Trash", "#Test_2", "#Test_3"... at https://www.mediawiki.org/wiki/User:Qgil/Sandbox#Test_2

The TOC can deal well with these anchors. How difficult would be to make that, after editing a section, the browser lands in the specific anchor and not in the first one? Sorry, I don't know enough to understand where MatmaRex's patch got stuck.

(In reply to Quim Gil from comment #22)

MatmaRex's patch

IAlex's patch, not mine :)

  • Bug 64147 has been marked as a duplicate of this bug. ***

jokes_free4me wrote:

(In reply to Quim Gil from comment #22)

The fact is that a MediaWiki page with several sections with the same label
will have a different anchor for each. See "Trash", "#Test_2", "#Test_3"...
at https://www.mediawiki.org/wiki/User:Qgil/Sandbox#Test_2

The TOC can deal well with these anchors.

There's still one gotcha though: if you have sections "Test", "Test", and "Test 2". The last two get the same hash-name!

Nemo_bis raised the priority of this task from Lowest to Medium.Feb 2 2015, 2:05 PM
Nemo_bis added a project: Epic.
Nemo_bis set Security to None.
Jdforrester-WMF lowered the priority of this task from Medium to Lowest.Feb 2 2015, 4:30 PM

Please don't change the priority on tasks that have idled for over a decade. This is rare (it requires the duplicate heading to be generated in a transclusion) and incredibly minor in impact.

"Epic" also doesn't really apply here. It's nontrivial to solve, but it's not really an epic.

Jdforrester-WMF, this is not rare (it happens routinely in Wikivoyage, where /* Get in */ and /* Get around */ have individual modes of transportation as the subheadings... in every article) and does not require the duplicate heading to be generated in a transclusion.

Go to a Wikivoyage destination article, edit one of the "Get around" subsections ("by car", "by donkey", "by boat", "by elephant"... whatever...) and hit 'save'. The edit will save correctly, but the browser will go to the same-name "Get in" subsection (and a few common transport methods recur constantly in "get in" and "get around" in voy:).

Whether this is incredibly minor in impact is a matter of opinion, but, because of Wikivoyage's fixed standard list of article sections, it's happening routinely and constantly.

Krinkle updated the task description. (Show Details)
Krinkle updated the task description. (Show Details)
Krinkle awarded a token.
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle unsubscribed.
Krinkle renamed this task from Return to page after edit of section when section name occurs multiple times may point to wrong section to Return to the correct section after section edit for a heading that exists multiple times.Feb 9 2019, 8:45 PM