Page MenuHomePhabricator

Investigate email: BH data storage/transfer issue for iPad donations
Closed, ResolvedPublic4 Estimated Story Points



Thanks! My first thought is the same as Peter's--maybe it's caused by an update to Safari on iPads? The Javascript code that logs the event when someone clicks to donate is in fact fragile, so I'd start there... Does anyone have an iPad? Or, alternately, we could try to check with an iPad emulator...

I'll also follow Max's suggestion and see if there have been any changes to EventLogging that might cause this... and I can do a quick query of the BH data directly from Hive, to see if things look different from there...
TTY soon, cheers,

On 30/08/17 10:39 AM, David Strine wrote:
Andrew or Elliott,

Is there anything we could suggest of investigate on our end?

On Wed, Aug 30, 2017 at 1:29 AM, Peter Coombe <> wrote:
The iPad banners should be identical to mobile. The fact it's only happening on iPad makes me wonder if it's an issue with Safari.

On 29 August 2017 at 23:26, Maximilian Pany <> wrote:
Hi all,

We noticed that something strange seems to be going on with the iPad BH reports (attached with mobile reports as a comparison): the most recent iPad BH reports for MY and ZA show only one donation each (the enBR report shows three donations), but the monitoring report shows 274 iPad donations for ZA and 128 for MY (and 110 for enBR). This mismatch seems to be restricted to iPad donations — we don’t see it for mobile or desktop donations.

This is nothing that seems obviously concerning from a fundraising perspective (since the monitoring report shows a reasonable number of donations), but we are wondering whether there might be a data storage/transfer issue with the iPad BH (event logging) data.

Are you aware of anything that recently changed with the way event logging data are handled? Or do you have another explanation?

Thank you!


Event Timeline

DStrine changed the visibility from "Public (No Login Required)" to "acl*WMF-FR (Project)".Aug 31 2017, 7:45 PM

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...

DStrine changed the visibility from "acl*WMF-FR (Project)" to "Public (No Login Required)".Sep 13 2017, 7:59 PM

Patch for review:

(Not sure why it didn't register automatically...)


  • 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.

On the iPad simulator, I confirmed that the method of sending the logs used in the above patch works, and that the event data makes it to the webrequest log.

Apparently the problem with the old code is that we were using a POST request (maybe to prevent caching? Or that's how EL used to do it? Note sure...). That was triggering a CORS block on the mobile site, since the EventLogging URL uses the desktop host. Possibly the browser was sending a "preflighted" request before the real one.

After changing the dataType to script in the $.ajax() call , it seems to work fine.

The issue doesn't exist at all on most platforms. This code is only run for browsers that don't support sendBeacon. For those platforms, we use our special code to try to ensure the request is sent before navigating to Payments wiki.

The normal EventLogging method used for Safari and company is also working fine, data gets to Hive without any issue.

What's confusing is that the rate of events/total non-event webrequests on the mobile site is much lower for Mobile Safari than for other mobile browsers. Data and queries forthcoming...

Change 377538 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Change 381047 had a related patch set uploaded (by AndyRussG; owner: AndyRussG):
[mediawiki/extensions/CentralNotice@wmf_deploy] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Change 381047 abandoned by AndyRussG:
BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Re-submitting with message about cherry-pick

Change 381047 restored by AndyRussG:
BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Gerrit silliness

Change 381047 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@wmf_deploy] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Mentioned in SAL (#wikimedia-operations) [2017-09-27T18:46:20Z] <catrope@tin> Finished scap: SWAT: T176762, T175358, T172023, T174719, and add html5-misnesting to Linter (duration: 22m 55s)

AndyRussG set the point value for this task to 4.Oct 23 2017, 2:21 AM

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:

Banner history samples  BannerLoader requests  Ratio    Browser         OS
337                     29450                  0.01144  IE Mobile       Windows Phone
283                     31335                  0.00903  Edge Mobile     Windows Phone
30188                   3415112                0.00884  Chrome Mobile   Android
492                     56437                  0.00872  Mobile Safari   iOS
681                     79616                  0.00855  Android         Android
3059                    385884                 0.00793  Chrome          Android
525                     102848                 0.00510  Firefox Mobile  Android

The logs are sampled at a 1%, so the expected ratio is 0.01. Mobile Safari is now close to that, similar to Chrome Mobile. (There is some variation among platforms, and a low rate for Firefox Mobile, which might bear investigation sometime, but for the most part the numbers look decent, I think.)

Here's the query: P6165

@Mpany do BH logs for iPads for the France campaign look OK to you?

Thanks!!! :D

@AndyRussG Thank you for all your sleuthing on this! The BH logs for iPad in the France campaign do indeed look OK to me now. They also look OK for the newest en6C tests. I will keep you in the loop as I keep monitoring them.