Fri, Jan 12
Wed, Jan 10
Here it is (temporary GitHub repo).
Wed, Jan 3
Tue, Jan 2
Dec 17 2017
Dec 6 2017
Dec 5 2017
Nov 29 2017
Nov 28 2017
The code above passed our browser tests on the beta cluster... :)
Hi! It looks like the problem is that the mw.popups object isn't created as soon as the module is loaded, but rather in an idle callback using mw.requestIdleCallback().
Nov 23 2017
Nov 20 2017
@Pcoombe thanks for testing...! :) I'll look at the popups code to see if there are any clues there...
Nov 14 2017
Closing, since this seems all good now :)
Nov 13 2017
Hi! As regards CentralNotice, no significant changes have gone out in that part of the codebase (client-side code running on nearly all pageviews) recently. None of the dependencies are new.
Nov 9 2017
Nov 7 2017
Nov 2 2017
Oct 31 2017
Oct 30 2017
Oct 27 2017
Here's how to use the provided patch from JS in a banner:
Oct 25 2017
Oct 24 2017
Here's the sort of situation where a library for this will come in handy: T177653
Oct 23 2017
It does seem like the most likely cause is that sometimes the banner loads before ext.popups, and sometimes it happens afterwards. We could verify by making the in-banner code register something like 'popupTestStatusUnkown' if mw.popups is not available... Not sure if it's worth it, though...
Confirmed via Hive that Safari on iOS is sending banner history logs at an approximately correct rate. For one day in the France FR campaign (2017-10-19), here are the ratios of BannerLoader requests vs. EventLogging requests to send sampled banner history logs, on the mobile site, for all major platforms:
I've attempted to reproduce again on production, and everything seems fine... So, apparently, the patch fixed it (or maybe the fix patched it)... @Jseddon, @Pcoombe, have you seen any indications of this bug since the patch was deployed? Thanks much!!!! :D
Oct 21 2017
Closing, since this is working fine on production! Thanks!!! :D
Oct 20 2017
Oct 19 2017
Oct 13 2017
Oct 10 2017
Sep 28 2017
Sep 26 2017
Sep 22 2017
Sep 21 2017
@Ejegg no, sadly, it's not... Gotta do so!! Thx for checking :)
K, reproduced locally and smoke tested the fix!!
Sep 19 2017
Hi! I've successfully reproduced this twice using campaigns targeting aa.wikibooks, on production. We're getting a funny object in ChoiceData, like an array with an empty slot. However, in that case, the JS code does not iterate over it correctly. So we can assume it suppresses all campaigns targeting the language/project combination with the affected ChoiceData.
Sep 14 2017
- I've been looking at this via webrequest logs in Hive and dev tools on an iPad simulator.
- Found an error that happens on mainly only mobile Safari (as mentioned in previous comment) and made a patch that fixes it.
- Still not sure of the exactly what changed to trigger this, though, and some numbers I'm seeing in Hive are also still confusing.
Patch for review: https://gerrit.wikimedia.org/r/#/c/377538/
Sep 12 2017
It's not a negligible number of users whose GeoIP location does not correspond to the location identified using their IP on the server when we process the server logs. Counting only users who are targeted by CN, this month it varied between 10 and 100 pageviews per minute.
Hmmm... Pivot doesn't show any FR campaigns going to logged-in users... Do we have any more specifics? Thanks!!!
Though if you filter the graph to show only desktop devices, the suppression of wlm 0217 is still only partial. (Just highlighting this because it might help us figure out what's going on...)
OK, thanks. So the campaign that caused this is wlm 2017-gb-blank?
Sep 8 2017
@Jseddon hey... I'm surely missing something... Don't see much in the last graph you linked to, above... Can you tell me which campaign suppressed which one in the test you did? Thanks!!!
Hi... Thanks for noticing this and for the careful description...!!! I'm not sure the cause is what you describe, though.... Looking just at desktop: while drop in wml 2017-gb impressions around 2:30 pm does seem to coincide with the enabling of C1718_en6C_dsk_FR, there are other similar drops in wml 2017-gb impressions that don't. For example, at 3:40 pm, while C1718_en6C_dsk_FR wasn't re-enabled until 4:09 pm.
I tried reproducing this locally as described, but everything seem worked normally. Any more details or thoughts on how to reproduce would be great! We could try to do so on the beta cluster...
Sep 7 2017
K found it! Somehow in this case we're sending the event via the desktop URL when on the mobile site, and so this is being blocked by a security policy. (The error said "not allowed by Access-Control-Allow-Origin".) Checking out the exact how and why now...
Yes, agreed that UBN isn't right at this point...
Sep 5 2017
Aug 22 2017
Proposal for prod DB cleanup: just rename the campaign. This should carry the lowest risk of creating DB inconsistency. We'd have to change the name in two tables: cn_notices and cn_notice_log.