@Jdlrobson I was just discussing with @cjming this morning my confusion around popups that have the .mwe-popups-no-image-pointerclass, the .mwe-popups-image-pointer class and popups that don't have either as they their usage didn't make sense to me and still doesn't make sense to me.

This was actually an issue I noticed before I7ca6c922b2f4615103e4162d96fd90d891deb1df, and I don't believe is a recent regression. E.g. If you checkout the commit before (1a62ae90cde931763c0fbbf06d1ecff98061ef9d you should see it.

@alexhollender I think I messed up the top spacing on this as well as for some reason there is 12px of top padding + 2px of top margin when T285786 clearly advises only 8px. It should only have 8px of top padding, correct?

@alexhollender Revisions done. Please check latest at https://patchdemo.wmflabs.org/wikis/e097002f78/w/

@alexhollender Can you please check https://patchdemo.wmflabs.org/wikis/608ecb4afa/wiki/Main_Page, and let me know what revisions I need to make. Please note that I am aware of deviations from the spec on the following items and wasn't sure how important they were to you:

Sorry for noise, this is a duplicate of T286822

Moving to upcoming per my POC patch above

POC above. There are several issues going on here (one of which is the text's margin getting clipped as a result of clip-path which @thiemowmde pointed out).

Moving this back to code review per the above patch ^^

Looks great!

Looks good!

we will need to address the spacing between the search (both collapsed & expanded state) and the user icons. should we address that here, or in T285786? cc @Jdrewniak

@alexhollender just a heads up - this has now been merged so it's best to do the design review on beta (https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page) rather than the patchdemo

In T284242#7206819, @alexhollender wrote:

notes from a discussion @nray and I just had:

• we will use a click event to handle the closing of the expanded search field, rather than trying to use the focusout event
• we will modify/remove the max-width on the input field so that it always takes up all available space when expanded
• I will file a separate task regarding the tab behavior for the search menu

How elaborate do we want the sticky header to be for this ticket? Do we want it to have all of the show/hide behavior of in the prototype: https://people.wikimedia.org/~jdrewniak/dip/p4.html#/en/wiki/Moon ?

@alexhollender can you please take a look at the above patchdemo and let me know if I've missed anything regarding the behavior or design? The icon spacing is another issue that I believe is being covered in another ticket.

We estimated this a small based on the simplest option of changing the id to pt-talk-alert in Echo. If we want to instead change the default id for this in core, then we should reestimate this ticket as that work would likely be larger than a small.

@Jdlrobson This bug will only surface on new Vector when $wgVectorConsolidateUserLinks = [ 'logged_in' => true ] . Given that $wgVectorConsolidateUserLinks is not enabled in production yet, I don't think it's currently affecting users

It's not clear to me whether this task is focused on real user monitoring (RUM), but synthetic tests to measure search performance were added to the dashboard as part of T251544 . I will close this ticket under the assumption that a more focused ticket for RUM can be created in the future if desired

I think the next question to figure out is whether we want this to only affect modern Vector or whether we want this in other skins as well (e.g legacy Vector, etc). We could, for example, get rid of the transformation logic in other skins and always have the talk link show e.g. in legacy Vector it could look like:

I've moved this back to code review because in the midst of writing up QA steps I noticed a bug involving modern Vector with the $wgVectorConsolidateUserLinks flag enabled (legacy/other skins aren't affected AFAICT) where the notification element has the wrong class (#ca-mytalk instead of #pt-mytalk) and the link is missing the title and accesskey attributes.

@ovasileva that sounds good to me! (and I agree with the approach of always keeping the talk link in the dropdown regardless of the notification status)

In T274428#6820477, @alexhollender wrote:

@ovasileva @Jdlrobson: @RHo just pointed out to me that the yellow notice doesn't get added to the user links, it is actually the Talk page link transformed into (or replaced by) the yellow notice. In other words the yellow notice IS a special version of the talk page link. I'm noting this because it might mean that option #2 in the description is more complicated than we thought (since in new vector the Talk link isn't exposed on the page, it's inside the user menu).

It was my understanding following our team conversation that we'll retain the position of the yellow bar /after/ notifications icons rather than before.

@MNeisler A fix for the final_state: vector bug has been deployed to all wikis. Can you please verify that the data you see is free of anomalies?

Okay, with the helpful context that the recently added logging code sent, I was finally able to reproduce the final_state: vector bug locally.

There are several options I've thought of with this ticket (please feel free to add others!):