Opened 4 years ago

Closed 4 years ago

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

Change History (6)

comment:1 Changed 4 years ago by sporz

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

comment:2 Changed 4 years ago by sporz

confirmed it affects antiadblockfilters.txt as well

comment:3 in reply to: ↑ description Changed 4 years ago 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 4 years ago by sebastian (previous) (diff)

comment:4 Changed 4 years ago 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 4 years ago 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 4 years ago by sebastian

  • Resolution set to worksforme
  • Status changed from new to closed

Closing as worksforme since it isn't reproducible with the current version.

Note: See TracTickets for help on using tickets.