966027 - [B2G][Gaia][Homescreen][e.me] Occasionally the Everything.me bar will show a blank search result when nothing has been entered in to the search bar

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

Description

[Lionel Mauritson]

Attachment: everything.png

Description:
Sometimes the everything.me bar will show below it "Everything" with no search terms after it. Normally it would say "Everything ducks" for example if the user searched for "ducks" but in this case it is though the everything.me bar initiated a search with no criteria.
The favorites star also appears but cannot be selected.

Repro Steps:
1) Update a Buri to BuildID: 20140127004002 and reset the device.
2) As soon as it is visible tap the everything.me bar and then wait.

Actual:
Underneath the everything.me bar which reads "I'm thinking of..." there will be the text "Everything" with no context or search criteria shown.

Expected:
The everything.me bar does not take "nothing" as search criteria. "Everything" is always followed by valid search criteria taken from the text box above.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Gecko: c40099a42c1f
Version: 28.0a2
Firmware Version: v1.2-device.cfg


Notes: Sometimes this can be seen more easily after the device has recently been reset to factory settings.
**The issue can occur randomly even when not using the steps above.**

Repro frequency: Roughly 2/10, difficult to repro but can happen at any time.

See attached: Image of issue and logcat of when issue occurred.

Comment 1

[Lionel Mauritson]

Attachment: Logcat of when issue occurred

Comment 2

[Lionel Mauritson]

Managed to catch it on video
http://youtu.be/YGEk0ht-w3Y

Comment 3

[Jason Smith [:jsmith]]

Can we check if this reproduces on 1.1?

Comment 4

[pfield]

This issue does not occur on Buri v 1.1. 

Environmental Variables:
Device: buri 1.1 com
BuildID: 20140130041201
Gaia: c434fe9a0e823029796805e141cfa983cda2d246
Gecko: 1b24a4178317
Version: 18.0
RIL Version: 01.01.00.019.281

Comment 5

[Jason Smith [:jsmith]]

I can reproduce this on a Buri 1.3 device & TCL Soul device 1.3. Weird - it's like clicking the e.me search bar doesn't work on a first click sometimes.

Comment 6

[Andrew Overholt [:overholt]]

Gregor, Jason suggested this may be a SystemsFE bug.  WDYT?

Comment 7

[Matthew Vaughan]

This issue appears to have started reproducing on the 11/23/13 1.3 build.

- Works -
Device: Buri v1.3 MOZ RIL
BuildID: 20131122123502
Gaia: 2cc78d696482e0434b584f5645af55e3105e59a2
Gecko: 3c4fc4279e6a
Version: 28.0a1
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20131123040202
Gaia: e48c2025b97f26db6e23c16d72095143d731b1fa
Gecko: 98aa428a392c
Version: 28.0a1
Firmware Version: V1.2-device.cfg

Comment 8

[Gregor Wagner [:gwagner]]

Aus can you take a look at this blocker?

Comment 9

[Jason Smith [:jsmith]]

The user impact of this bug of this bug will only impact a first usage of e.me. After you mash the e.me text field to get the keyboard to come up, this won't be reproduced again during phone usage.

Comment 10

[Jason Smith [:jsmith]]

https://github.com/mozilla-b2g/gaia/compare/2cc78d696482e0434b584f5645af55e3105e59a2...e48c2025b97f26db6e23c16d72095143d731b1fa

Comment 11

[Jason Smith [:jsmith]]

There's only one e.me patch in the regression range - bug 925970.

Comment 12

[Jason Smith [:jsmith]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c4fc4279e6a&tochange=98aa428a392c

Comment 13

[Jason Smith [:jsmith]]

Spoke with Aus in person about this bug - he mentioned this is a gecko bug, not a gaia bug. Seems to be easier to reproduce on b2g desktop in comparison to on device.

Comment 14

[Aus Lacroix [:aus]]

This appears to be a gecko bug related to forms. 

Timestamp: 2/5/14, 11:14:00 AM
Error: XPCOMUtils is not defined
Source File: chrome://satchel/content/formSubmitListener.js
Line: 15

It's unclear why formSubmitListener.js would be unable to load XPCOMUtils.jsm, however, this is a serious problem. :(

Comment 15

[Aus Lacroix [:aus]]

More interesting information -- If you use gecko (master) and gaia (v1.3) this issue is *not* present. If you use gecko (b2g28) and gaia (v1.3) the issue *is* present.

Comment 16

[Aus Lacroix [:aus]]

It looks like b2g28 nightly tinderbox build + gaia (v1.3, production build) will work just fine. Was this tested on a production build or not?

Comment 17

[Aus Lacroix [:aus]]

Will revise ETA once I find the root cause.

Comment 18

[Aus Lacroix [:aus]]

So, with the right combination of b2g28 + production gaia I'm so far unable to reproduce this. It does reproduce on a debug profile, but, that's not really a good test, unfortunately. Since the debug build has a lot of other issues that crop up which are absolutely never present in a release build.

Comment 19

[Aus Lacroix [:aus]]

Bug 960113 is likely to be causing some of the issues as well as satchel attaches itself to every text input field.

Comment 20

[Aus Lacroix [:aus]]

I'm going to make a special build that dumps the js stack so that we can at least figure out if that generic JS error is causing some real problems or not. Hopefully that will move this along.

Comment 21

[Jason Smith [:jsmith]]

Aus - An idea thrown around in triage is that we should bisect this to find the regressing changeset. That could help identify the root cause of the bug quicker.

What do you think?

Comment 22

[Gregor Wagner [:gwagner]]

(In reply to Jason Smith [:jsmith] from comment #21)
> Aus - An idea thrown around in triage is that we should bisect this to find
> the regressing changeset. That could help identify the root cause of the bug
> quicker.
> 
> What do you think?

Thats always a good idea!

Comment 23

[Gregor Wagner [:gwagner]]

It would also help a lot to find out when it started working again. Can we have the reverse regression range?

Comment 24

[Matthew Vaughan]

(In reply to Gregor Wagner [:gwagner] from comment #23)
> It would also help a lot to find out when it started working again. Can we
> have the reverse regression range?

Unfortunately this issue is still reproducing for me on the 02/12/14 1.3 build. 

In order to get this, I attempt the STR and if the bug does not repro, I reboot the device and try again. This allows me to get the bug in about 3 tries.

Device: Buri v1.3 MOZ RIL
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 25

[Jason Smith [:jsmith]]

(In reply to Matthew Vaughan from comment #24)
> (In reply to Gregor Wagner [:gwagner] from comment #23)
> > It would also help a lot to find out when it started working again. Can we
> > have the reverse regression range?
> 
> Unfortunately this issue is still reproducing for me on the 02/12/14 1.3
> build. 
> 
> In order to get this, I attempt the STR and if the bug does not repro, I
> reboot the device and try again. This allows me to get the bug in about 3
> tries.
> 
> Device: Buri v1.3 MOZ RIL
> BuildID: 20140212004003
> Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
> Gecko: ab07e61c2eb0
> Version: 28.0
> Firmware Version: V1.2-device.cfg

That's not what was asked for here - he's asking for a reverse regression window on 1.4, not 1.3.

Comment 26

[Aus Lacroix [:aus]]

If the regression window is indeed correct, I have a few more ideas up my sleeve to try out. ETA remains 2/14.

Comment 27

[Aus Lacroix [:aus]]

Jason, if we can manage to find when the fix landed on master in gaia (which would be after we branched for v1.3) that would help loads! Right now it's more stabs in the dark than anything else.

Comment 28

[Matthew Vaughan]

I am seeing this bug reproduce up to the 01/31/14 1.4 build. It looks like the Rocket Bar was implemented on the 02/01/14 build which changes how the e.me search bar worked and therefore prevents me from properly testing the bug as it is written. 

I am not seeing any problems from 02/01 and on, so I am going to put that build as when it started working again.

Reverse regression window for 1.4...

- Works -
Device: Buri v1.4 MOZ RIL
BuildID: 20140201160201
Gaia: 67f11d9b60750270f0bea834832e8108e95204e8
Gecko: d09f9a9f81ae
Version: 29.0a1
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.4 MOZ RIL
BuildID: 20140131095418
Gaia: aedd5c9636f305d4433491056a0ca984dfb859b1
Gecko: 735a648bca0d
Version: 29.0a1
Firmware Version: V1.2-device.cfg

Comment 29

[Aus Lacroix [:aus]]

Awesome, thanks Matthew.

Comment 30

[Aus Lacroix [:aus]]

So, the issue here is actually the target area. If your finger is slightly down from the bounds of the input box when you press you will be able to trigger the issue reliably. I can reproduce it at will now. It will only happen once though, because when e.me is loaded, the event will properly load the collection pressed OR focus the search bar. Basically, you need to fat finger the input and you can get it to happen. 

Now that I have reliable STRs and I know what's really happening it shouldn't take long to fix it.

Comment 31

[Aus Lacroix [:aus]]

Attachment: Pull Request - Also focus search bar when activationIcon is clicked.

Comment 32

[Aus Lacroix [:aus]]

Attachment: Pull Request - Tarako 1.3

Comment 33

[Amir Nissim (:amirn)]

Comment on attachment 8377880 [details] [review]
Pull Request - Also focus search bar when activationIcon is clicked.

Looks good.
Tested only on Nightly since I don't have a device with me on the weekend.

Thanks Aus.

Comment 34

[Preeti Raghunath(:Preeti)]

Amir,

Please fill the below approval form - 

Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: 
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:

Comment 35

[Aus Lacroix [:aus]]

Commit: v1.3  https://github.com/mozilla-b2g/gaia/commit/e631e7707a25af6310674f325131569cda61de6e
Commit: v1.3t https://github.com/mozilla-b2g/gaia/commit/af29153a7f3b45e7a22e8eed13f7fe416057ac02

[Approval Request Comment] 
[Bug caused by] (feature/regressing bug #): Bug 925970 https://bugzilla.mozilla.org/show_bug.cgi?id=925970
[User impact] if declined: This bug still occurs as described in the description and comment #30.
[Testing completed]: Based on updated STRs (See comment #30, https://bugzilla.mozilla.org/show_bug.cgi?id=966027#c30)
[Risk to taking this patch] (and alternatives if risky): None.
[String changes made]: None.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ghislain Aus Lacroix [:aus] from comment #35)

The point of going through the approval process is that patches are *NOT* to land until they are. Please revert.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Also, only 1.3T blockers should be directly landing on that branch. Everything else is being merged from v1.3 to v1.3t.

Comment 38

[Gregor Wagner [:gwagner]]

Comment on attachment 8377880 [details] [review]
Pull Request - Also focus search bar when activationIcon is clicked.

Description above.

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Reverted:
v1.3:  ffded319215ffe228fa6cbf1af221c4c0526b667
v1.3t: 1fb25d48fc75e1f022c3460690cc2acf7854aae4

Comment 40

[John Ford [:jhford] CET/CEST Berlin Time]

Hey Ryan,

Any ideas on how to deal with this now that it has 1.3 approval?

Comment 42

[Ryan VanderMeulen [:RyanVM]]

I reverted comment 39 and cleaned up the commit message. This will get to 1.3t via the regular merge process and doesn't need to be explicity double-landed.

1.3: 4b66307ce03a9842a587758ac1a4a12244c05c1e