Page MenuHomePhabricator

Add topic/read as wiki page buttons conflict with categories list on mobile
Closed, ResolvedPublic

Description

When mobile advanced mode is enabled (AMC), the categories list is shown on pages, and if the talk page has a category (such as a page issues category), it overlaps with our add topic and read as wiki page buttons:

https://en.m.wikipedia.beta.wmflabs.org/wiki/User_talk:ESanders_(WMF)

image.png (358×401 px, 21 KB)

Event Timeline

Change 885856 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Fix interaction of "Add topic"/"Read as wiki page" buttons with categories

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

Change 885856 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Fix interaction of "Add topic"/"Read as wiki page" buttons with categories

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

The selectors may be optimized:

Replace $( '#page-secondary-actions > *' ) with $( '#page-secondary-actions' ).children():

  • Chrome (which is an optimized browser), for 100,000 iterations: from 216 ms to 78 ms
  • Pale Moon (which lacks such optimizations), for 10,000 iterations: from 1790 ms to 16 ms (!)

Replace $( '.catlinks[data-mw="interface"]' ) with $( '.catlinks' ).filter( '[data-mw="interface"]' ):

  • Chrome, for 10,000 iterations: from 596 ms to 35 ms
  • Pale Moon, for 10,000 iterations: from 1162 ms to 84 ms

Change 886996 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Optimize selectors in mobile hacks

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

Thanks @Od1n, done. Feel free to just submit patches if you have the time.

(For anyone who'd like to verify that it's faster, you can copy some handy benchmarking code from T324523#8445297.)

Change 886996 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Optimize selectors in mobile hacks

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

Thanks for the patch :)

I had a look at this issue, and it might (to be confirmed) be helpful to move the optional .return-link from #bodyContent to the following #page-secondary-actions.

See in skin.mustache: Currently, the html-minerva-subject-link message is appended to #bodyContent, but it might rather be prepended to the following #page-secondary-actions.

That would be semantically cleaner, and might help to simplify the workaround you had to add here.


Even better, we might insert between #bodyContent and #page-secondary-actions the following:

{{#html-minerva-subject-link}}
    <div class="post-content">{{{.}}}</div>
{{/html-minerva-subject-link}}

(not tested, and of course the CSS of .return-link would probably have to be tweaked)

Then, the workaround of this ticket could be simplified to something like $( '#content' ).children( '.post-content' ).children().length (selector maybe to be refined, and caution, the .post-content class is quite generic and used elsewhere).