Closed Bug 1007663 Opened 6 years ago Closed 6 years ago

Avoid showing empty experiments list


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

Not set


(firefox30 unaffected, firefox31 fixed, firefox32 verified)

Firefox 32
Tracking Status
firefox30 --- unaffected
firefox31 --- fixed
firefox32 --- verified


(Reporter: gfritzsche, Assigned: gfritzsche)



(Whiteboard: p=5 s=it-32c-31a-30b.2 [qa!])


(1 file)

* have only one active experiment and no previous experiment
* go to the about:addons, experiments category
* click remove on the experiment

Result: empty addon list until reloading or switching categories
Expected: experiment shown as inactive or pending uninstall

Bug 992258, comment 5 pointed out that uninstall for addons is only triggered after e.g. leaving the category (until bug 612168 is fixed).
However, the experiment addon already get's disabled and we end up not showing it as it's not in the previous experiment list until it is actually uninstalled.

We can probably fix this by doing what we dropped earlier - marking PreviousExperimentAddon with a property previousExperiment instead of filtering by the addons disabled properties.
Summary: Avoid showing empty → Avoid showing empty experiments list
Flags: firefox-backlog+
Whiteboard: p=5
Assignee: nobody → georg.fritzsche
Whiteboard: p=5 → p=5 s=it-32c-31a-30b.2 [qa?]
Whiteboard: p=5 s=it-32c-31a-30b.2 [qa?] → p=5 s=it-32c-31a-30b.2 [qa+]
Disregard the background in comment 0, i think we should just show the undo element etc. here (and leave the rest for bug 612168).
Attachment #8422590 - Flags: review?(bmcbride)
Comment on attachment 8422590 [details] [diff] [review]
Show undo element after manual addon remove

Review of attachment 8422590 [details] [diff] [review]:

Attachment #8422590 - Flags: review?(bmcbride) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
QA Contact: andrei.vaida
Georg, I was unable to verify the fix for this issue because I couldn't actually install an experiment. 

Here are the steps that I followed in my numerous attempts on Nightly 32 2014-05-16, using two different machines:
1. Created a clean profile and added the pref "experiments.force-sample-value" as string, with the value "0.25".
2. Toggled the state of the pref "experiments.enabled", then closed the browser.
3. From the profile's folder, I deleted "experiments.json" file then launched back the browser.
4. Toggled again the state of "experiments.enabled" pref and closed the browser.
5. Launched back the browser, but the pref "experiments.activeExperiment" was still "false".
5.1. A new pref was also added eventually, "app.update.lastUpdateTime.experiments-update-timer" with the value "0", after repeating the above steps several times using the same profile.

I might be missing something here, since with the exact same steps I was able to install an experiment using Nightly 32 from 2014-05-07. Please let me know what are your thoughts on this.
Flags: needinfo?(georg.fritzsche)
Kamil can you help Andrei with QA tips for experiments?
Flags: needinfo?(georg.fritzsche) → needinfo?(kamiljoz)
Comment on attachment 8422590 [details] [diff] [review]
Show undo element after manual addon remove

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Telemetry experiments.
User impact if declined: Empty experiment addon list after clicking remove, undo element should be visible.
Testing completed (on m-c, etc.): Fine on m-c.
Risk to taking this patch (and alternatives if risky): Low, just visibility and test changes.
String or IDL/UUID changes made by this patch: None.
Attachment #8422590 - Flags: approval-mozilla-aurora?
Attachment #8422590 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

I took a quick look and it looks like the experiment that's being listed under "experiments.manifest.uri" has expired. As you can see below, the "endTime" check failed which basically means the current experiment expired: (expired on May 15, 2014)

"1400777176345	Browser.Experiments.Experiments	DEBUG	ExperimentEntry #0::isApplicable() - - test 'endTime' failed"

"1400777962433	Browser.Experiments.Experiments	TRACE	Experiments #0::evaluateExperiments() - added EXPERIMENT_ACTIVATION to TelemetryLog: ["REJECTED","","endTime"]"

Some quick tips when debugging experiments:

- Check "Enable chrome and addon debugging" (Open Menu -> Developer -> Toggle Tools -> Settings)
- Set "experiments.logging.level;0" (this will allow you to view similar logs that I added above)
- Open the "Browser Console" which will display logs when enabling/disabling "experiments.enabled"
- Make sure you're on the correct channel (the current experiment was only available under Nightly and would fail under Aurora or any other channel)
- Ensure that you set "experiments.force-sample-value" to match the experiments value or you'll spend a long time enabling/disabling to get the experiment installed

Not sure if Benjamin will launch another experiment any time soon, but your best bet is to create a local staging server so you can control all the parameters. In this case you would simply change "endTime" under the template and generate a new staging server that's not expired.

In the meantime you can use the server I use for testing, I changed the "endTime" to expire on July 15, 2014

- Experiment Info:
- Change: "experiments.manifest.uri;"

If you're going to use the above staging server for testing, make sure you change "experiments.manifest.cert.checkAttributes;false"
Flags: needinfo?(kamiljoz)
Benjamin, would you be able to increase the "endTime" on the development server for QA?

Development Telemetry Server:
Flags: needinfo?(benjamin)
No, the current experiment is done (and that really is a staging site). You'll need to set up your own server.
Flags: needinfo?(benjamin)
Gotcha, thanks Benjamin!

Andrei, you can either set your own staging server using the wiki I created or you can use the one I posted under comment #9.
(In reply to Kamil Jozwiak [:kjozwiak] from comment #12)
> Gotcha, thanks Benjamin!
> Andrei, you can either set your own staging server using the wiki I created
> or you can use the one I posted under comment #9.
Kamil, thank you for following up on this, your instructions worked perfectly.

I was able to confirm the fix for this issue on Nightly 32.0a1 (2014-05-22), using Kamil's staging server with:
 * Windows 7 64-bit [1],
 * Ubuntu 12.04 LTS 32-bit [2],
 * Mac OS X 10.9.2 [3].

[1] Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Firefox/32.0
[2] Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0
[3] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Whiteboard: p=5 s=it-32c-31a-30b.2 [qa+] → p=5 s=it-32c-31a-30b.2 [qa!]
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.