@ovasileva: Is this really on normal priority and not high or UBN!?

This is F'ing annoying..

I'm not sure when this went wrong, but please fix it asap.

This used to be handled by the function isNavPopupsEnabled() which nowadays seems to be inside src/settingsDialog.js.

Hey @TheDJ, have you enabled both the beta feature and the gadget or are you seeing this on a wiki where, say, both are enabled by default and are conflicting?

Interestingly mw.config.get( 'wgPopupsConflictsWithNavPopupGadget' ) is true but I still see both :)

@ovasileva is the expected behavior to completely turn off PagePreviews related code (Popup, EventLogging, etc.) when NavPopups is enabled?

In T160081#3159162, @bmansurov wrote:

@ovasileva is the expected behavior to completely turn off PagePreviews related code (Popup, EventLogging, etc.) when NavPopups is enabled?

The Popups schema provisions for the gadget being enabled. I'd hope that the EL-related code remains enabled.

Change 346792 had a related patch set uploaded (by Bmansurov):
[mediawiki/extensions/Popups@master] Disable Previews when Navigation Popups Gadget is enabled

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

Change 346792 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Disable Previews when Navigation Popups Gadget is enabled

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

The navigations popup gadget doesn't seem to work on the BC. So to sign off we'll either need to install it there or wait till we can verify on mediawiki.org on 11th April.

It's not a perfect test but enabling the gadget, even if it doesn't work, should disable Page Previews. This can be verified on the BC.

@Jdlrobson, @phuedx, @bmansurov : tested in beta cluster and works fine. However, let's wait until the 11th and have @ABorbaWMF
test it in production just in case:
Testing steps:

1. When page previews are a beta feature:
   • - Enable navigational popups
   • - Enable page previews as a beta feature
   • - Hover over a link

Expected behavior:

• Navigational popup appears (for beta cluster: nothing appears)

2. When page previews are a live feature

Does anyone know how we can test this? (i.e. - do we have a list somewhere with the wikis that have navpops as a gadget and what the name of the gadget is for each wiki?

Change 347291 had a related patch set uploaded (by Phuedx):
[operations/mediawiki-config@master] pagePreviews: Enable NavPopups gadget detection

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

In T160081#3163842, @ovasileva wrote:

2. When page previews are a live feature

Does anyone know how we can test this? (i.e. - do we have a list somewhere with the wikis that have navpops as a gadget and what the name of the gadget is for each wiki?

I wrote a script that attempts to automatically generate this list and the corresponding config. ^ I'll deploy that config today.

I've scheduled rOMWC43732e1bb2c9: pagePreviews: Enable NavPopups gadget detection for deployment during today's European SWAT.

Change 347291 merged by jenkins-bot:
[operations/mediawiki-config@master] pagePreviews: Enable NavPopups gadget detection

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

Mentioned in SAL (#wikimedia-operations) [2017-04-10T13:16:25Z] <hashar@tin> Synchronized wmf-config/InitialiseSettings.php: pagePreviews: Enable NavPopups gadget detection - T160081 (duration: 00m 40s)

I'll check it today

Change 347523 had a related patch set uploaded (by Pmiazga):
[mediawiki/extensions/Popups@master] Sanitize gadget name

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

I tried to find what's wrong with Popups and Gadgets integration but it's pretty strange. I pushed a fix that should help in some cases (https://gerrit.wikimedia.org/r/#/c/347523/2 - will fix es, fr, nl and similar names with spaces) but the simple English is still broken as wiki has a correct/sanitized gadget name. If I copy&paste gadgets definitions to my local instance everything works like a charm 🤔.

What's more strange, on the https://yi.wikipedia.org I after enabling both PagePreviews and NavPopups I can see both. If I type in console mw.config.values.wgPopupsConflictsWithNavPopupGadget I get true -> which should disable PagePreviews but somehow both features are visible

@pmiazga: After panicking about this for the last 30 minutes – my shower was ruined – @bmansurov's change only started riding the train this week, i.e. you'll see it on yiwiki on Thursday, 13th.

^ There's a minor issue with the unit tests in rEPOPa74e3a7dfa0e: Sanitize gadget name.

Merging @pmiazga's change is blocked on T162876: Intermittent failure of mwext-qunit-jessie for Popups.

The patch that needs review is https://gerrit.wikimedia.org/r/#/c/347523/ ?

Change 347523 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Sanitize gadget name

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

the reminder should work, closing this for now.

Quoting my response to the invitation:

What happens if we find a bug next Wednesday? Do we reopen [this task] and fix it? In that case is it unplanned sprint work? To an external observer (anyone who hasn't been invited to this event), yes. To us, no.

Why not put this task in the Blocked Externally column of sprint 96 and commit to QAing and signing it off per our usual process?

I'm a fan of distinct tickets when possible, so I don't think it's inappropriate to create a followup task if further work has to be done. That way, this work can remain logged as resolved effort, and you get the benefits of granularity. Does that work?

I'm not sure about this - I'll make a note to discuss for retrospective. If signoff is all that's needed in a task and we've done the work, I think creating additional tasks/reminders only increases time spent and confusion. My preference would be to keep the task open - if it's sitting in signoff or blocked externally as Sam suggested it doesn't distract from the remainder of the sprintwork significantly. For this task in particular - I think it's fine with a reminder, as it is working on mediawiki, but I still don't see the harm in waiting for a few days and resolving then rather than introducing more complexity

Correction.. the fix is in wmf21 which is not live on simple wiki at time of writing. I've updated calendar invite for tomorrow.

This does not appear to be working on simple wiki but Yiddish and others are fine. Any ideas to why please add them over on T164044.