Note: This ticket is extremely difficult to replicate. I would say that the expected QA is that nothing breaks after the change (mainly in the positioning of the search Preview), I will then follow up by checking logstash

Found a solution. I can use the OOUI icons as the above mentioned set of icons have also been added to the OOUI widget

@Volker_E I was asked to do this task and I wanted to reach out to make sure I do it correctly and or wait longer to make sure things are done right.

I have a question for you @Sneha what do you mean by short article info?

Thank you guys for the detailed explanation of the problem.

After a discussion with @Sneha we have agreed to NOT show the snippets if page infos are missing (Description, Thumbnail, sections). This is a change from the current AC that also requires us to wait for the commons request.

Thank you for the answer Andre..

I have implemented the first version of the Board.

Hi Andre,

Reviewed locally, event triggered on click:

HI, @Sneha thank you for the explanation above, those questions are now sorted. Unfortunately, I still need your help to clarify something about what we are showing (this was a follow-up to a discussion I had with Matthias).

There are two parts to this:

1. We have to decide how many links to actually fetch. The more link we fetch the more the request take (it is prob milliseconds extra, but still adds to the user waiting) - Currently we just return 10
2. Decide how to show it. I do not think we can show them all, for example for an article could have over 500 links.. we cannot show them all..

The ticket itself was this on: https://phabricator.wikimedia.org/T321944

h @Sneha I have started to work on this story and I have a question or two...

This is an expected feature (that we may need to discuss)

I can confirm that this is done and deployed. All information surfacing the Search Preview are coming from our newly created API, the FE API ha been removed as part of this ticket

I can confirm that this is done and deployed. All information surfacing the Search Preview are coming from our newly created API, the FE API ha been removed as part of this ticket

I can confirm that "Change the UI to request just the data it needs" has been completed and live since October.

@matthiasmullie Can you just confirm that you expect to backport T326957 into the release and therefore this is not required? I remember we discussed about it, but I want to make sure that I am not providing the wrong info here..

This is not required anymore as T326957 has been completed already.

I have investigated this further and actual development was required. I have completed the following (now in review):

The issue mentioned above is going to be fixed on T326962

@Sneha you cannot reproduce it because the fix has already been merged into Beta.

I have implemented a quick fix to prevent the search preview to work with these results. This will not show the arrow next to the results and will also ensure the search preview does not open when these results are clicked.

Please note that I have found more than one issue on safari while fixing this and they were all related issues:

• When The result has just image and sections the image was getting truncated or removed
• Changed the way we set the width of the search preview so that we can now see the right border of the section (before it really looked like there was more behind the screen)
• Fixed it so that there is a bounce effect in all cases
• Fixed the Main image when its aspect ratio was less than 0.75, safari was adding a grey border at the bottom
• On mobile, if image is very large its width will be set to a max of the screen - 50px (like we do for commons images) otherwise the rest of the content is not visible