Opened on 09/08/2015 at 08:15:02 AM
Closed on 09/09/2015 at 09:54:30 AM
#3008 closed defect (worksforme)
Safari anomaly @1.9 launch: too many active users
Reported by: | sporz | Assignee: | |
---|---|---|---|
Priority: | P5 | Milestone: | |
Module: | Unknown | Keywords: | |
Cc: | sebastian | Blocked By: | |
Blocking: | Platform: | Unknown / Cross platform | |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Environment
Safari: Adblock Plus 1.8.12.1423 and Adblock Plus 1.9
Observed behaviour
The number of weekly active users on Safari after the launch of Adblock Plus 1.9 were twice as high as usual for about two weeks.
The same anomaly could be observed for development version 1.8.12.1423, too, but no other versions were affected.
All applicationVersion and all downloadCount >=1 are affected.
From the logs it seems that the lastVersion parameter is set to something different than it should be, but not something fixed. It's probably set to the date of the users update to the new version of Adblock Plus (1.9 or 1.8.12.1423) or at least very near to that date.
The anomaly might be related to #2757, with data being reset to an older state; not to 0 as in the ticket. It can also be an independent phenomenon.
It has not happend again after the 1.9 launch, so I'd recommend low priority.
Attachments (0)
Change History (6)
comment:1 Changed on 09/08/2015 at 08:38:47 AM by sporz
comment:2 Changed on 09/08/2015 at 10:52:20 AM by sporz
confirmed it affects antiadblockfilters.txt as well
comment:3 in reply to: ↑ description Changed on 09/08/2015 at 04:14:04 PM by sebastian
- Cc sebastian added
Well, if it doesn't happen with the current version of Adblock Plus for Safari, that is 1.9.2 (or 1.9.2.x for the dev build), then there is nothing we can do. All users have already been updated to that version, except those who have disabled automatic updates. And there is nothing we can do about these users.
comment:4 Changed on 09/09/2015 at 08:52:08 AM by sporz
Assuming it is a variant of #2757, I'm concerned that it affected safari and chrome differently. If there's a reason to that it's okay. If not, it may be a symptom of a deeper problem that COULD affect future changes.
comment:5 Changed on 09/09/2015 at 09:42:18 AM by sebastian
Yes, #2757 effects Chrome and Safari differently. So far we didn't observed any effect on Safari. That is because we use synchronous APIs there. Though we wrap them in asynchronous fashion. But the timeout we introduced there is way shorter than the response times of the asynchronous storage API on Chrome. Moreover, to reliably reproduce the issue we had to make Chrome open multiple websites on start. Something that AFAIK isn't possible with Safari. But yeah, theoretically that issue could effect Safari as well, but is less likely to become visible there.
comment:6 Changed on 09/09/2015 at 09:54:30 AM by sebastian
- Resolution set to worksforme
- Status changed from new to closed
Closing as worksforme since it isn't reproducible with the current version.
This does not affect notifications.json download, but affects exceptionrules.txt.