Adding T322436: Codex should provide mechanism for flushing icons and T333392: Button: Increase padding of icon-only buttons on small screens as subtasks to reflect that they're related / blocking this parent task - please move these around if this is not accurate!

Great to have these! Signing off for now, as we've done the appropriate measurements. When we pick up other alternatives we can compare this output to other potential implementations as a next step, but we will have a different ticket for these.

I made some changes just now to reflect how this will fit into our Technical Decision Making Proposal process:

• Updating title to "Measure performance of cookie-based anonymous client preferences" to cover current scope, which is measuring -- but not yet analyzing -- the performance of the cookie-based approach
• Making a subtask of https://phabricator.wikimedia.org/T333878 , which is the TDMP phase at which we will be measuring the performance of various approaches. This better reflects that the cookie-based approach as currently outlined is one of multiple possible proposals in this space, and we will need to measure this as we measure these other approaches, then compare performance against the metrics we have identified.

This will now be handled by means of https://phabricator.wikimedia.org/T333867 , the official TDMP request. I am closing this ticket and moving all subtasks to this other ticket.

We are going a slightly different direction with this proposal, and will formalize according to the template laid out in this doc. I can link to the issue shortly when it's available.

I approve this access as Kim's manager - thanks!

Signing off on this issue now, as it's in production, tested, and we have next steps established.

As a starting point, @ovasileva Would you be able to set a priority on this issue? (we're planning to dupe https://phabricator.wikimedia.org/T327070 here, at which point arguably this issue should be in the web board as the other one is).

We discussed this just now in DST refinement. In short, we are not sure if this is in Typeahead search or not, but before this, we're not sure if this issue is reproducible outside of this particular user's report. For next steps, we need a QTE engineer to attempt to reproduce the specific issue identified with the "Telugu Phonetic" keyboard layout on a real Windows PC.

This appears to be the same user and the same issue as reported over on https://phabricator.wikimedia.org/T327070 - We covered in DST refinement just now and recommended closing this out as a duplicate and handling followup there

Hi all -
An update -- first, procedurally:

1. We're going to close out https://phabricator.wikimedia.org/T328802
2. Move this task to our board (https://phabricator.wikimedia.org/project/view/6366/), set priority and effort estimation to match that ticket, and assign to @nray to add functional regression test steps as had originally been in scope for that other ticket
3. @Jdlrobson will add more parameters here about what is in and out of scope for these test cases.
4. Once test cases have been written out, we will pass this back to @Ladsgroup to merge
5. Once merged, we'll test and post test results back here.

Closing as declined - we will handle writing these test cases in https://phabricator.wikimedia.org/T326147

We talked through this just now in our task estimation meeting, and had two outcomes:

1. We're going to close this out, merge this with the parent task (https://phabricator.wikimedia.org/T326147), and move that ticket to our board in place of this one, setting priority and effort appropriately on that task.
2. @Jdlrobson will add what is in and out of scope for our test case investigation to that original ticket

Hi @daniel -
Thanks for weighing in. I'm realizing I could have been a bit more clear in my original post as to specific timing, sequencing, and responsibility. I can look to clarify that for now:

Hi everyone -
I wanted to weigh in on the sign-off criterion, "Work out next steps for continuing the persistent settings functionality."

Hi everyone -
I wanted to add a bit of context here in case it's helpful. @Jdlrobson 's current patch is tentative. He crafted it based on some initial back and forth with the Partnerships team and Google, but for a handful of reasons, we're not sure this is the best approach, and we'd like some help in better understanding alternatives, as well as potential fallout.

Hi everyone -
Firstly, @Ladsgroup , thank you for finding this issue and working through this fix, and thank you for flagging us (the Web Team) about this as well.

Yes, this is standard browser behavior for refreshing the page with an anchor in the URL. We can close

Closing this ticket. This was initially meant as a placeholder ticket for further test-related work, but reading back over this, the scope is quite broad. I met with @Edtadros yesterday, and we've got a plan going forward to tackle pieces of this incrementally, starting with requirements gathering. This will be handled with separate, upcoming tickets

Re-reading this report, it may actually be that this is the same issue as described. We can ask for further clarification -- I guess it comes down to whether readers have the expectation that when you refresh the page it takes you to the same anchor/has the same part of the TOC highlighted

(A side note, I should note I encountered this in trying to reproduce this issue, which I believe is actually separate - thus using the same link as in that report, apologies if this confusingly brought the two streams together!)

This is now done! Kudos to @AnneT and @Catrope for contributing to this process and helping us to find great intern candidates!

Mentioning https://phabricator.wikimedia.org/T321424 here to conceptually link this work with potential upcoming work for Web - would be interesting to consider how / when that work could be phased relative to this, we should discuss this going into next quarter's planning

Marking as complete for now, but this may tie into DST's work around "CSS-only components" for https://phabricator.wikimedia.org/T321351 , which will be kicking off next year. Mentioning here to link - we can/should consider this further when that work is a bit further along

Hi @TAndic -
I took a look at this yesterday briefly to understand what fix might be required and to see if I could quickly address / there were any gotchas. I do think it's better for longer-term maintenance if T&S can fix.

This is great, thank you all for taking these on!

Several subtasks are still in progress here - for next steps, we should look to close out tasks that represent the majority of use cases, then refine remaining token-related tasks together in our Engineer/Design sync on Wednesday

Looks excellent, thank you for putting this together! Signing off now and closing.

Looks excellent, thank you for putting this together! Signing off now and closing.

Here's the latest scc output for the repo:

I will be spinning out the Chinese issue cited above into a separate ticket shortly - it is likely a different issue

Could you confirm this by doing the same test but with the arrow keys landing on a different item that isn't the footer?

I briefly tested this out this morning and I was able to reproduce what may be a similar issue.

Agreed with all of this - my mistake on keypress (this was off the top of my head / without confirmation, and thus incorrect!), and agreed about general spotty handling of key events in a multilingual context.

So - some specific thoughts on recommended next steps:

A few relevant pieces of info from the original description:

• "The search box does not transliterate the Roman skript to Telugu" -- this suggests the user is using the Windows "Telugu Phonetic" input method specifically, as MacOS does not use transliteration from latin script. The way it works is that you type latin characters and then it provides its own popup with suggested transliterations - you can see this in action here (4:57 in the video)
• Timing may be implicated somehow: the user mentions: "...as soon as the [page is loaded. If I leave the page and come back immediately, then it starts working."
• "It is not the case in the old Vector (High priority)" - this is a regression from previous search box behavior in older Vector
• "when I move to to type new word, the first letter is erased, and only the subsequent letters are displayed " - this appears to result from replacing the actual contents of the input field itself for some reason
• "Some of the typed letters do not appear as they are supposed to. Ex: when I type ree,vee,kee etc., they are supposed to appear as రీ,వీ,కీ. Instead they appear as రి,వి,కి (They are "printed" correctly, but don't appear correctly)." -- by this the user means ర (ra) + రీ (long i / ī) produces ర (ra) + ిి (short i) in the input field -- this is a different vowel.

Hi @aaron - I wanted to ping here as you're listed as the maintainer of the FlaggedRevisions Extension here. Would you be able to help provide additional context on this issue, and/or otherwise point us to folks who might be able to help? We've separately scheduled a pairing session to discuss this issue together in person, but any amount of insight you can provide as to the behavior we're seeing would be appreciated!