In T417194#11613629, @lwatson wrote:

I noticed an overlapping issue with the revised long header text behavior.

My fears around the variable height were mostly unfounded, and @JScherer-WMF confirmed preferring to move ahead with this: https://6bba64531c.catalyst.wmcloud.org/wiki/International_Space_Station?useskin=minerva&mpo=minerva-toc-sticky:treatment&useparsoid=0#Education_and_cultural_outreach

Unclaiming the task for now - I'm currently working on something else, so it's up for grabs!

#1 - I did not realize this behavior was expected here. I've crossed it out from this ticket and moved it to T413403, where I'm currently working on handling the scroll position; seems fitting there.

Per T416244

In T413400#11567915, @bvibber wrote:

This acceptance criteria seems iffy still:

• TOC does not show when editors explicitly disabled it through NOTOC (e.g. Main page)

Some initial investigation:

I had a quick stab at this here, but while the options generated in that patch seemed to work well in echarts editor, it timed out in my environment. Would need further looking into.

Above patch addresses area chart gaps.

@JScherer-WMF question about this button: looks like there's a bunch of padding on both sides of the icon/text, which is not there when the button is the another state. It feels a bit odd to me that the appearance changes when clicked, so I was wondering whether this difference is intentional or not? See https://740e6eaae6.catalyst.wmcloud.org/wiki/Berlin?useskin=minerva&useparsoid=0&mpo=minerva-toc-button:treatment for what it looks like.

@Etonkovidova This is not enabled by default - it's part of the Minerva TOC experiment, which can be triggered through ?mpo=minerva-toc-button:treatment and ?mpo=minerva-toc-sticky:treatment. My apologies for not making that clear!

@aude Patch has been merged. Does anything else need to happen here, or can we close out this ticket?

Potentially relevant experiment: https://f1dc349aee.catalyst.wmcloud.org/wiki/Border_Collie?useparsoid=0&mpo=highlight:treatment#:~:text=Agility%20Dog%20Association%20of%20Australia

Note: I don't think that (at least) the Parsoid side of things will work with MobileFrontendContentProvider, as MFNamespacesWithoutCollapsibleSections will have a different configuration on production than it will be on the wiki using MFCP, and so the content will be rendered differently.
I confirmed with locally-rendered Parsoid pages that it works, though.

Good catch, @Etonkovidova.
This one would trigger under slightly different conditions (part of the problem, the <space> before the punctuation, was not already in the message right before the username, so it only affects usernames that have both space + punctuation), but it's essentially the same problem!
Another patch in CR.

loggedOutPageVisit.js also confirmed good to remove.
Patch updated.

In T414362#11517005, @mfossati wrote:

In T414362#11516400, @matthiasmullie wrote:

@mfossati loggedOutPageVisit.js as well, or do we expect to run that again at some later point?

Not sure, CC @SherryYang-WMF

@mfossati loggedOutPageVisit.js as well, or do we expect to run that again at some later point?

FYI I wasn't really able to reproduce through above scenario, but loading it on my phone (iPhone; width around 390px) with sections collapsed consistently showed the issue upon expanding the section.

In T408875#11407166, @TheDJ wrote:

Could IntersectionObserver be used here instead to address this issue?

Not sure

1.2 may be moot if T413404 ends up with not allowing Parsoid output.
1.3 action=parse&prop=tocdata still returns data when NOTOC is present, so if we're going with that and want to respect NOTOC, we'd need an additional check for the NOTOC directive.

As for enwiki: I don't know whether/how it is possible to make future experiments inactive, but I've updated the enwiki experiment to 0% (instead of 0.1%) of traffic and pushed it 5 years in the future.
If we've decided to either run or abandon it for real, let's create a new ticket to actually schedule/remove that experiment.

End date changed to Jan 09. Moving to QA to confirm afterwards.

According to https://mpic.wikimedia.org/experiment/sticky-headers, it is scheduled to run until Jan 11 (Sunday) - do we want to keep it until then, or close it off earlier on Friday?

No worries! I think we could've lived without the sprint tags for all those already closed, but thanks for restoring them! :)

Thanks!