@Niedzielski Thank you for removing that tag

Will write more on this later, but this is what the profile looks like with the event bus not listening to section-toggled events for images (effectively turning lazy loading off when sections are toggled).

@Gilles Can you please clarify that the problematic click handler this task is referring to is when you click on a reference link like the one pictured below and then black reference drawer pops up?

@ovasileva I retitled this as a spike so I believe it can be estimated now, and I will place it in the upcoming column

After discussing with @ovasileva, I'm closing this task out as the original problem has been resolved (and has been in production for awhile now). Furthermore, the additional toggler/lazy image load performance problems that I listed in the task description are captured well in T225946.

In T225124#5273804, @alexhollender wrote:

@nray I think either way (OOUI or native) is fine. Whatever is easier.

@alexhollender I'm assuming we also the date widgets to work? Currently on beta they are the native date fields, but on: https://en.wikipedia.org/wiki/Special:Contributions/NRay_(WMF)?useskin=minerva the OOUI date widgets are enabled.

Is there a difference between for example:

$img = self::parseHTML('<img>')
and

$img = $('<img>')
and

$img = $( document.createElement('img') );

@alexhollender the color should be corrected on https://en.m.wikipedia.beta.wmflabs.org/wiki/Spain now

@alexhollender you're right. The above ^^ patch should fix the color, but it unfortunately introduces some tech debt in the process as it makes it differ from the default OOUI icon structure which sets an explicit black stroke color on the icon. We'll see what the other devs think as well , but it might not be as clean/straightforward as one would think/hope :(

@ovasileva Would you mind if I closed this task out? It looks like the original problem that the task was created for has been resolved, and we have more granular tasks in T225946 and T206354 to deal with the remaining performance issues.

@Peter Thanks so much for your detailed analysis! The browsertime tool looks cool.

In T222630#5256649, @alexhollender wrote:

@nray I didn't realize that wikidata items could show up on user pages. I'd say the priority here is main namespace pages, though the ultimate goal would be parity with desktop. Not sure how much scope that would add.

@alexhollender To clarify, should this link only be added to the overflow menu in the main namespace? Or should it also be added to the user namespace overflow menu as well if the wiki supports it? I believe the namespaces that wikibase client can work are configurable [1]

I removed the second AC and moved it to its own task at https://phabricator.wikimedia.org/T225556

I need to add qa steps

In T224819#5246905, @alexhollender wrote:

Thinking about this some more:

from "Acceptance Criteria" section of the task description
If a substring matches the user's search input, that substring is bolded regardless if the substring is at the beginning or not.

I don't know if this would be possible unless we changed the way the search works. Currently if I type "Ak" into the search field I am only shown results that start with "Ak". Maybe I'm missing something, but I don't understand how the proposed idea would be possible given how search works currently.

Thanks for bringing this up @Krinkle. tldr; I agree it could be better named and I ran some tests to see if I could make an attack vector.

@pmiazga is there anything left to code review on this?

I moved this back to needs analysis because I think we need to sort out whether the second AC bullet point I've listed, "If a substring matches the user's search input...", is actually necessary so we can know the scope of this task while estimating.

@Krinkle Are there any other points you'd like to add to my read of the menu situation performance? I'd love to hear any insights your team has on it as well!

I know this task has been lingering and so I wanted to provide an update on this:

MFUseDesktopSpecialHistoryPage will need to be changed to tackle this

I can replicate this bug, and I think there are potentially two parts to this ticket we may want to address (described in developer notes)