Closed Bug 1141896 Opened 6 years ago Closed 3 years ago

[Metrics] Resumed web search are not counted

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: shinglyu, Unassigned)

References

Details

Attachments

(1 file)

*** Description
Searches are not counted if no internet connection is present. But Firefox OS automatically redo the search after the connection comes back. Not quite sure if we need to count it or not.

*** Steps to Reproduce
1. Disable all internet connection
2. Click the rocket bar
3. Type "Mozilla", then press the "magnifier glass" icon at the bottom-right of the keyboard (You should see the "<search provider> requires an Internet connection" screen)
4. Enable Wi-Fi

*** Expected Results
The search is is performed automatically when the Internet comes back. And there should be a search count of 1

*** Actual Results
Search count = 0

*** Other Notes
As discussed in comment 17 of bug 1126524, we decided to not count the search. But since Firefox OS has this auto-resume behaviour, I guess we need to re-think if we should count it, and how? 

*** Reproduction Frequency
3/3

*** Build
  Gaia-Rev        3f032238a52f08e4c2f68a47ad065a96eb22d470
  Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9ae4bcc9b5f2
  Build-ID        20150309162503
  Version         37.0
  Device-Name     flame
  FW-Release      4.4.2
  FW-Incremental  eng.cltbld.20150309.201258
  FW-Date         Mon Mar  9 20:13:09 EDT 2015
  Bootloader      L1TC000118D0
Flags: needinfo?(thills)
blocking-b2g: --- → 2.2?
May be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1141891, waiting for Tamara's input on either of those bugs to see if they will be handled separately.
Hi Bhavana and Shing Lyu, I think this is a different problem then bug 1141891.  I have a fix in the works for 1141891, but need some more investigations into this one.  So pretty sure at this point they will be handled separately.

Thanks,

-tamara
Flags: needinfo?(thills)
Comment on attachment 8576402 [details] [review]
PR for counting searches for selected suggested searches.

Sorry.. canceling this review.. I posted the PR on the wrong bug.
Attachment #8576402 - Flags: review?(marshall)
Hi Shing Lyu,

This is indeed a good question.  I'm going to NI Ravi on this question.  We had initially decided not to count the offline searches as you mentioned.  Right now it's not counting them.

Here are the use cases I can think of:

1. [NO AUTO-RESUME] User goes into airplane mode, starts a search and then that search automatically resumes when they land if they go back out of airplane mode.  I would think this is unlikely because they would most likely have exited out of rocketbar to do something else.

2.  [NO AUTO-RESUME]User consciously goes into airplane for some other reason, or turns off wifi/data connection in settings and then searches, they get the message that there is no internet, they exit out of the rocketbar, turn their network back on and then go back into the rocketbar (vs going through the search app that is backgrounded).  In this case, the search is not resumed.  They are left with the search term, but no search results. 

3.  [AUTO-RESUME]Same as case 2 *except* they don't exit out of the rocketbar to turn on their network, they pull down the screen that lets them turn the network back on.  In this case, the search is auto-resumed and the results are there.

4.  [NO AUTO-RESUME]Same as 2/3 except they hit Cancel on the message that says that they need an internet connection.  In this case, there is not a search window in the background to resume.  So, it would be just like case 2.

5.  [AUTO-RESUME] User hit "check settings" on the on the error page and then enables network from there.  

My $.02 is that at this point, it's probably best to not count them.  If we do count the offline searches, we'll have to make some changes to avoid doing duplicate searches in the case of auto-resume.  This may be a little difficult.  Also, it seems a toss-up to me which is more likely between the resuming and non-resuming use cases.  

Ravi, if you can comment and let us know direction on this one.  

Thanks

-tamara
Flags: needinfo?(rdandu)
Whiteboard: [systemsfe]
Michael or Hema...for your metrics triaging
Flags: needinfo?(mtreese)
Flags: needinfo?(hkoka)
Whiteboard: [systemsfe]
 
> 
> My $.02 is that at this point, it's probably best to not count them.  If we
> do count the offline searches, we'll have to make some changes to avoid
> doing duplicate searches in the case of auto-resume.  This may be a little
> difficult.  Also, it seems a toss-up to me which is more likely between the
> resuming and non-resuming use cases.  
> 
> Ravi, if you can comment and let us know direction on this one.  
> 
> Thanks
> 
> -tamara

We have already accommodated the MVP late metrics requirements for 2.2. I suggest pushing the offline search count out to the next release. Lets get the 2.2 code base stabilized with what has already landed. Ravi, please provide your input. 

Thanks
Hema
Flags: needinfo?(hkoka)
Lets resolve this AUTO-RESUME scenarios when we add offline search count. Lets schedule that for the next release (post 2.2).  For 2.2, we'll note that there may be lower counting of online searches, since the AUTO-RESUME cases will not be counted.
Flags: needinfo?(rdandu)
(In reply to rdandu from comment #8)
> Lets resolve this AUTO-RESUME scenarios when we add offline search count.
> Lets schedule that for the next release (post 2.2).  For 2.2, we'll note
> that there may be lower counting of online searches, since the AUTO-RESUME
> cases will not be counted.

Ravi,

Thanks! Please add this to the Metrics backlog that you are tracking for upcoming releases (post 2.2).

Removing from 2.2? and on to backlog bucket

Thanks
Hema
blocking-b2g: 2.2? → backlog
Flags: needinfo?(mtreese)
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.