User Details
- User Since
- Dec 4 2023, 11:20 AM (122 w, 4 d)
- Availability
- Available
- LDAP User
- Arthur taylor
- MediaWiki User
- Arthur Taylor (WMDE) [ Global Accounts ]
Thu, Apr 9
As long as we have the data bridge enabled (which is the case on Wikidata in production)
Are you sure? I don’t see any bridge-related ResourceLoader modules on Wikidata. (In the production config, wmgWikibaseRepoDataBridgeEnabled is true on Wikidata, but wmgWikibaseClientDataBridgeEnabled is false.)
Ah - no, I was just assuming. If it's not there at all then that makes the advantage in fixing QualityConstraints much clearer
Spike findings
Re. double load. It is certainly the case that in the current implementation, we send the layout for the MEX sections as rendered by php-vuejs-templating in the initial HTML:
Wed, Apr 8
Added a patch with a proof of concept for lazy-loading the interactive Vue elements - should speed up the first load and read-only experience, with only a slight delay for users that then click on edit or add statement.
For the Sandbox Item the results look much worse, and worse for MEX than for Desktop, so it seems like something is systematically worse for MEX. Will try and dig into that.
I generated Lighthouse reports for MEX and Desktop against prod for a simple item (https://www.wikidata.org/wiki/Q37315170), and it looks like we score okay. MEX has a couple more accessibility issues than the desktop interface, but those shouldn't be too hard to fix (and are not in the scope of this ticket)
Weird. I do have echo installed, and don't see oojs-ui-widgets load if I disable Kartographer / Data Bridge and apply my patch.
Tue, Apr 7
Fair. If I disable quality contraints and data bridge, oojs-ui-* does indeed not get loaded. I'll take a look at whether it's possible to make those loads conditional on (the absence of) MEX.
I instrumented the sortDependencies function in mediawiki.loader.js to try and track down where our oojs dependencies are coming from, and it looks like removing that won't be all that simple:
Wed, Apr 1
@ABran-WMF sure, but I think my patches have now been merged (by retrying a bunch of times)
And this - different but maybe related: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83-selenium/38340/console
Saw this issue again this morning: https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-vendor-mysql-php83/24578/console
Tue, Mar 31
Reviewed this together in task time on 31.3 and decided to go with option #3.
Fri, Mar 27
Thu, Mar 26
@Lucas_Werkmeister_WMDE That change definitely fixes the issue.
Wed, Mar 25
The default width of the map component is 310 px - this is defined in CachingKartographerEmbeddingHandler.php and has no configuration options. This means that without changing the PHP we will always receive a version of the component that expects to have at least 310px width - a width that the current design doesn't accommodate in the statement view (as currently implemented - it's about 5-10px too narrow on a screen width of 375px).
Tue, Mar 24
Merged, updated the cold-start data and redeployed.
Mon, Mar 23
- Review of investigation / questions