Closed Bug 1055854 Opened 10 years ago Closed 8 years ago

Data reporting notification shown to Nightly user after bug 862563

Categories

(Firefox Health Report Graveyard :: Client: Desktop, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gps, Unassigned)

References

Details

I updated my Nightly to a build with bug 862563 in it and I was shown the Firefox data notification info bar on startup. I don't believe that should have happened since we didn't bump the policy version.
Flags: firefox-backlog+
Flags: qe-verify?
Gavin, can we get this in the next iteration?
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(gavin.sharp)
Added it to the spreadsheet for 35.1
Flags: qe-verify? → qe-verify+
Points: --- → 5
Assignee: nobody → georg.fritzsche
Iteration: --- → 35.1
Status: NEW → ASSIGNED
I don't see this with some variations i tried like:
* new profile on 2014-08-10 nightly
* convince the notification to pop up early
* follow manage link
* confirm prefs are set as expected
* update to current nightly
... no notification is shown. Also the code around userNotifiedOfCurrentPolicy() looks sane.

Any further details here or can we call this WFM?
Flags: needinfo?(gps)
It's entirely possible my local profile had additional FHR foo in it causing things to get in a weird state and causing the notification to get shown.

I'm willing to call this WFM.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(gps)
Resolution: --- → WORKSFORME
I've seen this with every Firefox profile that upgraded from before to now, so I don't think this is fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Hm, any more details? Did you ever dismiss the notification on the older Nightlies?
I can't reproduce this at all going from 2014-08-10 to 2014-09-03 after dismissing it (and hence the proper prefs being set).
Flags: needinfo?(benjamin)
I probably can't QA this more now, but I bet Kamil would be willing to try!
Flags: needinfo?(benjamin) → needinfo?(kamiljoz)
QA Contact: kamiljoz
Quick Update:

I've been trying to reproduce the issue on several VM machines and I've installed m-c on several machines at home.. I'll be updating the browsers and using those computers over the weekend and see if I get the notification to appear after I've dismissed it after installation.
I went through a bunch of test cases for several hours on several different OS's/machines/VM's and couldn't get the notification to appear the second time around once it's been dismissed/closed. I used three different machines during the weekend and couldn't reproduce the problem.

Test Cases:

- once the notification appeared, closed the latest m-c and moved machines date ahead by one and re-launched m-c
- once the notification appeared, updated m-c to the latest version and closed m-c, moved the machines date ahead by one day and re-launched m-c
- once the notification appeared, closed m-c and moved the machines date ahead by  day than re-launched and updated m-c
- tried updating older fx's going back as far as 2014-08-16 (comment bug # 862563 comment # 2014-08-16)
- on my OSX MBP, updated m-c 4 times (Fri - Mon) and never received the notification the second time around
- on two different Win 8.1 machines, updated m-c 3 times (Fri - Mon) and never received the notification the second time around

However, the one thing I'm noticing is that the telemetry notification only appears once even though the user doesn't dismiss the notification. For example:

- download the latest fx (m-c), you'll receive the telemetry notification
- close fx without selecting "X" or "Choose What I Share" on the telemetry notification
- move the date forward by one/two days and re-open fx (you won't receive the telemetry notification)

I remember the old behavior was that the notification would appear until the user selects the "X" or "Choose What I Share". I just want to make sure this is the correct behavior.

Benjamin, I couldn't reproduce the problem. I also asked QA to keep an eye out for this on Friday but haven't heard back from anyone. Is there anything else that I can do to try to reproduce this? Perhaps something I missed? Is the behavior I mentioned above correct?
Flags: needinfo?(kamiljoz) → needinfo?(benjamin)
I tried for a few minute today to reproduce this using a clean profile and running old/new nightlies with various date changes along the way. I couldn't reproduce it.

I don't know what to do with this. I guess we can call it WFM for now, but I really do expect that there is an issue here that beta users are going to see, and we'll see reports of this again there :-(
Flags: needinfo?(benjamin)
The next-best thing i can think of is letting SUMO know so they know where to go if they see it.
Hey Tyler, Madalina said that user advocacy people might help here with keeping an eye out for details or STR from affected users.

This bug is inactionable right now because we don't know what triggers it.
Some users may see a reshowing of the data reporting notification after bug 862563, even though they probably already dismissed the notification before that change (i.e. implicitly accepted it).
Flags: needinfo?(tdowner)
Or maybe Michael, you have an idea?
Assignee: georg.fritzsche → nobody
Flags: needinfo?(mverdi)
Iteration: 35.1 → ---
On irc Tyler said they would look out for info related to this bug.
Flags: needinfo?(tdowner)
Flags: needinfo?(mverdi)
Has anyone seen or been able to reproduce the original problem?
(In reply to Kamil Jozwiak [:kjozwiak] from comment #15)
> Has anyone seen or been able to reproduce the original problem?

No feedback for a while, closing.
Status: REOPENED → RESOLVED
Closed: 10 years ago8 years ago
Resolution: --- → WORKSFORME
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.