Thanks for bringing this up @Edtadros , I can't replicate the expanded/collapsed being in the wrong state, but the missing label I'm going to call a browser bug.

and it's live! Just want to say thank you @Ladsgroup for taking the lead on this deployment, and @Bharatkhatri351, your work is finally live!

Nuts. Unfortunately I spotted an issue with the wiktionary.org portal before deployment today.

Changes look good, here's a screenshot of what I see after the patch. The languages button doesn't have an aria-label, instead it has an aria-labelledby that points to the <label> element next to it. That label element, (somewhat unconventionally) has an aria-label attribute that should be read by screen-readers. This makes sense because text of the aria-label is more explicit than the it's text content. i.e. whereas visually the languages button says "250 languages", screen readers will hear "Go to an article in another language. Available in 250 languages". 👍

@bwang wait is there really one called "Navigation navigation"? 🤔

@jwang sorry, I should have been more explicit about that issue. There was a typo in the instrumentation as it was initially deployed (my bad).

Agreed. This is good enough.

Alright, signing this one off then :)

I tested this today on production and I'm not seeing this issue anymore, so I think the solution looks good :)

It looks like this answer to "Investigate why skin preference is set to empty string for various users" has been answered, and the answer is captured in T54777 and T54778, so work on this problem can continue on those tickets.

Thank you @Jdlrobson and @jwang for resolving this issue!

I can confirm that the accesskeys works :)

Oky doke! I just set up the cron job on the server. With that I think all the AC have been fulfilled :)

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

I've looked at events per session on frwiki and compared to jawiki, ptwiki and dewiki, (to see if maybe a single session responsible for a large number of events) and there doesn't seem to be any obvious outliers that would suggest that.

Ok. now I get it.

Just to note the approach taken here. The patch above depends on enabling the edit button for everybody by default, then hiding it for all users who are not in the treatment bucket.

@Ladsgroup , I took another look at this but unfortunately I was unable to reproduce using your instructions. I created a new page, switched to source editor, then saved the page.

hi @Ottomata, I've clicked around Hue and verified that events are being logged successfully at about the volume as before (about 25k per day). Would you like to verify this as well & sign this off?

@Ladsgroup oh no! I hope this wasn't the case, unfortunately I'm having trouble reproducing. I tried on a sandbox production page, here's a video of what I did:
https://drive.google.com/file/d/1mb0ihCh6_TnpATfutdvhKMwiA1Ukdgc5/view?usp=sharing

@Ottomata I'm planning to deploy the change to the portals repo Thursday March 24, afternoon deploy window. After that, we should start seeing production events :)

The task related to mediawiki_web_ui_scroll was created as T303297. That and all related AB test tasks are now tracked in "[Goal] Begin table of contents A/B test" T304169.

hi @Ottomata , I've merged the schema to analytics/legacy and have a patch up for the portals repo as well as mediawiki-config. I'm guessing we'll be able to test the new schema once it's been deployed via the train? (that's happening 4 times this week so it shouldn't be long)

lgtm

Does WMF still maintain Wikimedia-Portals?

@Aklapper "maintain" might be to strong a word, perhaps "benignly neglect" would be more precise.

@Rocky_734 its like your issue was resolved when I updated the pagecounts.json script related to T300434. The link to the Santali language wikipedia now appears on www.wikipedia.org.

@bwang sorry, that's a bit confusing. From the screenshots @Edtadros posted AC1 is a pass.

• Only top-level sections should expand and collapse. Subsections should always remain expanded.
• Clicking the heading of a top-level section will expand it. Clicking it again won't do anything, the section will remain expanded.
• Only clicking the arrow button beside the section will collapse it.

@ovasileva looking over this requirement once more, I have one question. It's clear how this metric should be instrumented for the old table of contents. In the new treatment, where the ToC is pinned, I don't think the scroll-back metric will be attainable (since the new ToC is pinned and therefore not scrollable, unless it overflows the viewport). Do we want to measure this only for the old ToC? Or measure it differently for the new one?

Yeah this should be pretty doable with some CSS trickery. Here's a codepen with an example: https://codepen.io/j4n/pen/mdqvzMQ

@IKhitron we're actively working on the table of contents and bugs like this may appear temporarily due to caching. Are you still seeing this issue?

@Ottomata great, should we merge the schema addition to analytics/legacy before, after, or in tandem with the migrated instrumentation?

@Rocky_734 I've looked at this issue and it seems like the problem is related to how the search options are populated.

@Amire80 yeah this is pretty bad. The fact that I'm just getting around to replying to this ticket two months later speaks to the maintenance status of this tool and the portals repo in general.

I was curious what this specific bucketing would look like.

So I've looked into the event logging migration. The documentation is very good! I think I have everything I need to start work on this task.

hi @Ottomata, I'm just in the process of scoping out this work this week (I anticipate we'll get started on it shortly after that) and I'll reach out if I have any questions :)

Given the requirements from the spreadsheet in the description, we'll be using 4 schemas to track the required events for this test.