This feels like it's asking for an X/Y plot type instead of column series as a feature request?

Have reproduced it on another section and investigating.

In T409325#11421951, @Catrope wrote:

Eric showed me this feature today and I found a bug: when I view https://en.wikipedia.beta.wmcloud.org/wiki/Paris?useskin=minerva&useformat=mobile&stickyHeaders=1&useparsoid=1 in Chrome with mobile device emulation (I used the "Pixel 7" dimensions, 412x915px) and I scroll from the "Etymology" to the "History" section, there's an oscillation bug where the ext-readerExperiments-stickyHeaders on the "Etymology" heading is rapidly removed and re-added and removed again. This doesn't happen for any of the other section transitions on this page, and it also doesn't happen on the non-Parsoid version of the page for some reason.

Tweak and tests merged -- _closed resolved_. :D

Another bug: the sticky header isn't wide enough to cover the entire width of the screen, so very occasionally some things on the page can appear beside it when you scroll. This happens for example on pages with a large number of references:

I added unit test coverage in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1213584

Ready for QA on bullet points "peeking", live sites have the patch. "International Space Station" on enwiki, "International Cooperation" section should have some nice bullet lists

In T410694#11417535, @Joe wrote:

A suggestion: when reporting the latencies, it would be useful to also have the standard deviation, which ab(1) provides, as the numbers seem so close to each other that the differences might well be within one standard deviation from each other between various solutions. That might help pick the one with the better size/performance tradeoffs better.

Very happy with the results of my holiday hacking: T410694#11418011

Experiments benchmarks in cpu and ram so far:
https://docs.google.com/spreadsheets/d/14n6r7LQ5bDuAO2G8gSso3QZ__ByQzrUCtC1JvJYr-g0/edit?gid=0#gid=0

Current state:
https://docs.google.com/spreadsheets/d/14n6r7LQ5bDuAO2G8gSso3QZ__ByQzrUCtC1JvJYr-g0/edit?gid=0#gid=0

The string interning cache seems to de-duplicate well enough but the total cache memory definitely seems a *lot less* with the smaller files from indirecting fallback and/or keys. Key indirection is a much smaller win.

Fixed the merging of arrays and preloads; seems to be working quite well, with no cost when no fallbacks used and a _possible_ slight cost visible on for instance zh-hant which loads several fallbacks. It still beats CDB consistently. :)

I though this would fix the date formats on en-gb and zu (pulling up all fallbacks and using the merge logic on arrays) but it didn't, I still have to figure this out:

I've made a stab at using the existing fallback language logic in LCStaticArrays by adding a "fallback" mode that doesn't merge in fallback keys, and instead loads them from the other cached languages at runtime:

Did a quick benchmark of whole-web requests; since the difference is clearly visible enough I didn't bother to do a synthentic benchmark:

We're going to split out a task for follow-up: T411125

In T409325#11379956, @JScherer-WMF wrote:

Our experiment won't run on pages referred from "Related articles" e.g.

https://en.wikipedia.org/w/index.php?title=The_Expanse_(novel_series)&wprov=rarw1%20?stickyHeaders=1

In T409325#11379970, @JScherer-WMF wrote:

Bullet points "peak out" from beside the scrolling headers

Should I backport the patch to wmf.3 for group2 today or shall we just wait until group2 rolls out wmf.4? I assume that should be coming soon.

Backport deployed! Appears to be working.

Scheduled for deploy this coming morning UTC (yes I know it's late my time):

• https://schedule-deployment.toolforge.org/window/1764144000

For the record, Popups indeed picks problematic sizes for tall images, such as 479px and 436px.

@Ladsgroup any help with core code review would be welcome:

• https://gerrit.wikimedia.org/r/1211230

If there's any objection to this core patch I can move the logic into Popups, I just..... really think it belongs in core. :)

Quick peek at the situation:

• prod config has $wgThumbnailSteps = [ 20, 40, 60, 120, 250, 330, 500, 960 ];
• for suitably aspect-ratio'd images it seems to ask for a 640px image on my 2x display, 480px on a 1.5x display, and presumably would a ask for 320px on a 1x display
  • for taller images it may pick a non-standard width (untested so far but looks like it from the code)
• we want for the JS to apply the same logic as File::adjustThumbWidthForSteps() in the PHP side
  • if the requested width is smaller than the smallest step, use the smallest step
  • if the requested width is exactly a step, use the step
  • if the requested width is between steps, round one step down
  • if the requested width is greater than the highest step, use the requested width

Taking this as I've touched relevant other thumbnail bits recently and should be able to figure this out :)

Fix merged, backported and deployed. <3

Patch looks good in second rev; code is clean and it now checks for both missing data cells and explicit nulls; +2ing for merge. :)

deployed and DONE. followup work -> T410711

Ok here's my holiday hacking plan for later this week:

I think the shared compression dictionary is a dead-end, it's not worth the savings to generate it.

Got my dev setup's l10n cache from original 850M down to *164M* by replacing the CDB for the id->id mappings with fixed binary array files, which should also be faster to query.

In T99740#11352349, @tstarling wrote:

From the point of view of image size and memory usage, it might be better to merge all the languages into a single file, and combine identical values by having a numerically indexed global value array. Maybe also abbreviate the message keys by mapping them to integers. We can tolerate a little bit of indirection at runtime.

Riffing on a comment by Tim Starling about indirecting strings I whipped up a quick proof of concept changing the CDB-backed cache to use indirection tables for message keys and strings, and compress the serialized strings with deflate:

Ok the reconciliation with wgThumbnailSteps is complete: getting 500px is now officially Fine And Good as the smallest size on the QA test link :D

Output of spike: confirmed we want to tweak WikimediaEvents' SessionLengthInstrumentMixin to be xLab-Experiment-friendly as a short-term solution and are happy to help out ́Experiment Platform with a patch from our end, if they can provide code review.

Above patch is to reconcile wgMediaViewerThumbnailBucketSizes with wgThumbnailSteps by bumping 400 to 500. This will make behavior consistent for MultimediaViewer whether it can "guess" resized URLs based on a source thumbnail or not. Follow-up work to spike T410556.

@Ladsgroup Woohoo! I thought it might be something like that. On a slight investigation:

Ok we can follow that up in T410556: figure out why it's coming up as 500 instead of the configured 400, then decide whether to bump the config to 500, leave it at 400, or chose 480 based on expected usage and the presence of the constraint.

It seems that something is pushing the 400 bucket up to 500 anyway -- all the other sizes are going through as I expect, and the config var is fine. Let's file a followup task to a) figure out why it's doing that and b) if we'd prefer 480 or 500 anyway, tweak it as a followup.

Ok, the SessionLength mixin looks perfect. Starting on a proof of concept patch just to make sure I understand what it looks like (then I presume we have to finalize the schema details)

Update config with [400, 960, 1280, 2560] is now LIVE on beta & production group0 (includes test.wikipedia.org). If nothing explodes I'll roll it out to group1 and group2 next week and we can close.

Looks like sessionTick.js saves into a specific event (mediawiki.client.session_tick) and schema (/analytics/session_tick/2.0.0), so either we'd have to modify it to accept our data, or use a port or different method though that would be extended if need be.

Updated config patch with [400, 960, 1280, 256] on beta & group0 scheduled for this afternoon :D

This is done in ImageBrowsing as follows:

If I'm reading correctly, the WikimediaEvents system will track session lengths if wgWMESessionTick is enabled in MediaWiki config which ... I can confirm is enabled on both beta and production wikis.

Mystery solved -- the MobileFrontend patch fixes a bit in the legacy Toggler.js that was overriding the correct scroll position. Fix should not break current production system while working correctly when position:sticky and scroll-margin-top or scroll-padding-top are in use.

❌ AC1: No console error Cannot read properties of null (reading 'src') appears

A good start! If we're thinking of moving some of those pending items to passive maintenance or community maintenance we should include definitions for these too, maybe something like:

T409349 can either live separately or merge in here.

In T406379#11316957, @Edtadros wrote:

12. ❌ AC10: No CORS or loading issues occur on iOS 15+, Android 10+, macOS, or Windows browsers