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

This does not affect notifications.json download, but affects exceptionrules.txt.

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.

Last edited on 09/08/2015 at 04:14:27 PM by sebastian

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.

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.