Closed Bug 750130 Opened 11 years ago Closed 11 years ago

Telemetry doorhanger appears then disappears very quickly (< 200ms) on first start after factory reset


(Firefox for Android Graveyard :: General, defect)

Not set


(firefox14 fixed, firefox15 verified, firefox16 verified, blocking-fennec1.0 +)

Firefox 15
Tracking Status
firefox14 --- fixed
firefox15 --- verified
firefox16 --- verified
blocking-fennec1.0 --- +


(Reporter: jaws, Assigned: Margaret)



(Keywords: regression)


(1 file)

I did a factory reset on my Android gingerbread HTC Sensation 4G. I then downloaded Nightly Fennec Native and upon first run the telemetry opt-in doorhanger appeared then disappeared in too short of a time for me to make a decision.
Might have something to do with bug 749624
Sites still loaded after this, so I don't think it's related to bug 749624.
Yep, still see it.
blocking-fennec1.0: --- → ?
JP thinks we had a similar problem on desktop too, but I don't know if it's related to the mobile problem.
Assignee: nobody → margaret.leibovic
blocking-fennec1.0: ? → +
It was probably caused by this patch from bug 746380: We no longer check to see if the location change URL is the same as the previous URL (since we now rely on the sameDocument property from JS). The tab URL is probably set to about:home, then we get a location change for about:home, and this will end up calling "tab.removeTransientDoorHangers();".
FWIW: I can repro this on Galaxy S2, no factory reset. 
- Uninstall all Firefox builds
- Conduct a clean install of Aurora
Attached patch patchSplinter Review
Brian's comment was the right diagnosis. I also found that uri == documentURI in the initial handleLocationChange, no matter what page the app is launching, so this problem extends beyond about:home.

Adding persistence = 1 to the doorhanger fixes this issue because it makes it hang around through this first location change. This shouldn't cause any problems because we only call _showTelemetryPrompt during the same startup path that calls addTab() and triggers this onLocationChange event.

The change from bug 746380 means that we're never following that |if (sameDocument)| path when the first page is loaded. This doesn't seem to cause any problems, but it is definitely a change, so we may want some more QA coverage on what goes on with the location bar during first page load. I actually wonder if this may have inadvertently fixed some of our issues with wrong titles/urls when opening links from external apps.
Attachment #619690 - Flags: review?(bnicholson)
Attachment #619690 - Flags: review?(bnicholson) → review+
Target Milestone: --- → Firefox 15
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 619690 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #): bug 746380
User impact if declined: telemetry prompt disappears unexpectedly
Testing completed (on m-c, etc.): just landed on m-c
Risk to taking this patch (and alternatives if risky): low risk, only affects telemetry doorhanger
String changes made by this patch: n/a
Attachment #619690 - Flags: approval-mozilla-aurora?
Blocks: 746380
Attachment #619690 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Ehsan Akhgari [:ehsan] from comment #12)

Hm? How did we end up with two mozilla-central changesets? Is that because of the double landing? (Does that not break anything?)
Yes, I double-landed several patches while inbound was frozen for bug 750661.  The merge just becomes a no-op in this case.
Verified/Fixed on:
Nightly Fennec 16.0a1 (2012-06-14)
Aurora Fennec 15.0a2 (2012-06-13)
Device: HTC Desire Z
OS: Android 2.3.3

Telemetry door-hanger stays in the view.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.