| Krinkle | |
| Jul 4 2020, 9:46 PM |
| F31917427: Screenshot 2020-07-04 at 22.44.38.png | |
| Jul 4 2020, 9:46 PM |
| F31917425: Screenshot 2020-07-04 at 22.44.26.png | |
| Jul 4 2020, 9:46 PM |
E.g. https://meta.m.wikimedia.org/wiki/Special:CentralAuth/Timo_Tijhof_(WMF)
The headings have the sortable icon and are cursorsed in a way that suggest interactability, but nothing happens on-click (no error either).
https://meta.wikimedia.org/wiki/Special:CentralAuth/Timo_Tijhof_(WMF)
(Example after sorting by editcount or group to find where the account is actively use.)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T257127 "Global account info" looks sortable on mobile but isn't | |||
| Resolved | phuedx | T250851 Allow skins to override mediawiki.page.ready initialisation to enable search JavaScript to be swapped | |||
| Resolved | None | T233340 Add sortability to sortable tables for readers of the mobile web site | |||
| Resolved | Peter.ovchyn | T257265 enable mediawiki.page.ready in Minerva | |||
| Resolved | TheDJ | T194451 Make the tablesorter CSS not expand the width of unsortable columns |
@Jdlrobson This ticket isn't about making it work. It's about fixing the bug where the styles wrongly load when they shouldn't. This is not a problem on regular page views. Something is happening here specifically. Do we know what that is?
So my understanding is that jquery.tablesorter.styles and jquery.tablesorter are both loaded but this page is relying on mediawiki.page.ready to enhance the table rather than doing it itself.
You could add a line to do this:
$('#mw-centralauth-merged table').tablesorter()
but I'm not sure how well tablesorter works if run twice... Thus my recommendation of doing T250851 first.
This is not a problem on regular page views.
Which pages are you seeing table sorter work on mobile btw?
I'm not. The problem is that Special:CentralAuth is rendering an interface to users with sorting buttons that don't work. On articles we render tables plainly, without sorting buttons. Hence there is no problem there.
The issue is the combination of:
@Jdlrobson so do we need to conditionally load these modules? Is it OK to rely on MobileContext::usingMobileDomain() for this?
I think CentralAuth should be calling $('#mw-centralauth-merged table').tablesorter() itself and making sure that it isn't subject to mediawiki.page.ready. The mediawiki,page.ready call should really only for be user generated content.
CentralAuth is loading both jquery.tablesorter.styles and jquery.tablesorter. Core is re-loading both. Minerva unloads both, but CA re-adds them.
If you want to override CA's decision then both should lack target=mobile and thus both end up silently removed from the queue in the way the target system usually does.
Or we can set target=mobile on both, rely on Minerva unloading them for most things, but otherwise allow CA to own its (good or bad) choice to load these anyway.
.... and, that's exactly what we do already. The reason it doesn't work, is because it isn't also in the same stubborn way loading mediawiki.page.ready nor calling .tablesorter() itself. Okay, I understand your point.
Adding these calls inline seems icky, but it's certainly what the current situation calls for so sounds good to me.
There's a proposal by @Fomafix that I quite like, which is to decouple this a bit further and let the module handle these on its own. That would avoid this problem, and also remove the need for each consumer to have its own init code for it. More declarative, and yet still an enhancement insofar that both modules can still be safely omitted (or not loaded in the first place, eg. when third parties like Apple Dictionary render the core HTML without a skin).
More about that in change 503101. At this point, that might be a better investment assuming this isn't so urgent.