Change 848312 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/SearchVue@master] [POC] Log 'open-searchpreview' event

https://gerrit.wikimedia.org/r/848312

Change 848312 abandoned by Matthias Mullie:

[mediawiki/extensions/SearchVue@master] [POC] Log 'open-searchpreview' event

Reason:

https://gerrit.wikimedia.org/r/848312

When a user refresh a page that has Search preview already open (auto open on load) do not trigger an event

I need more detailed instructions for this AC. Shall we emit an open event only the first time user opens the page with the quickView=<article_name> param in the URL (like this) and all other page refreshes do no emit this event? Or should we completely disable open event emitting if quickView=<article_name> param is present even if the user visited the link that instantly opens QuickView for the first time?

cc: @matthiasmullie , @cchen

@SimoneThisDot Do you remember the history behind this AC:

When an user refresh a page that has Search preview already open (auto open on load) do not trigger an event

Like @vadim-kovalenko said, there's no mention of what to do when a user loads the page with quickView=<article_name>, without it being a refresh (e.g. link shared)

Per https://phabricator.wikimedia.org/T321080#8358827, we want to track close-searchpreview even when the user didn't explicitly close quickview themselves (by closing the page)
Following that reasoning, I would assume that we also want to track open-searchpreview when it was opened automatically via the query param.

If we want to differentiate between "new page load" and "refresh", I guess we could use something like window.performance.navigation.type == window.performance.navigation.TYPE_RELOAD to check (but IDK how good browser support is). But something like that is not possible for the close-searchpreview counterpart, so we may have more closes than opens.

However, I'm guessing that this AC was simply meant as "don't track automatic opens" (both new page load and refresh) - am I right?
If so, since we want to track "automatic close" (by closing browser window), I think that we also want to track automatic opens after all?

@cchen: do we also want this 'open-searchpreview' event to be captured when a user enters the page and a quickview automatically opens (because of a query param in the url)?

@matthiasmullie It was just my assumption on the way things were defined and discussed in the other ticket. Your explanation (about the automatic close) makes sense, so I guess we should remove that AC and also record automatic open!

Any objection guys: @vadim-kovalenko @cchen ?

Related patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SearchVue/+/850546

@cchen - please review the following - does the current behavior look ok?
(1)

• When a user clicks on the same search result DO NOT trigger an event

Just to clarify - does it mean that no additional "open-searchpreview" events will be recorded? The current behavior - when a user clicks on the same search result, the search preview will be closed and `"close-searchpreview" will be recorded since the quick preview would be closed.

(2)

• When an user refresh a page that has Search preview already open (auto open on load) do not trigger an event

When a page with opened searh preview will be refreshed - two events will be triggered:

"close-searchpreview" and "open-searchpreview"

@Etonkovidova...

We can wait for Connie to reply, but as far as I know ( i wrote the tickets and since then some decision have modified my understanding of this):

1 - Yes, that is correct, we will trigger a "close-searchpreview" when clicking on the same result
2 - After discussions with other teams, We have concluded that the following flow (of triggering Close and Open messages) when an user refresh is the correct flow (consistent with other people using this kind of instrumentation).

To summarise, both expected behaviour. If Connie agrees, we should change the ticket requirements

@Etonkovidova @SimoneThisDot

1. Yes, when clicking on the same result, we are expecting "close-searchpreview" events.

2. Agree, refreshing page with searchpreview opened will trigger two events.