1062516 - Unable to add ev.me apps/websites to the homescreen from Search view and Browser app

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Josh Schmitt [Joshs]]

Description:
User is unable to add an app to the homescreen as the page is unresponsive.
   
Repro Steps:
1) Update a Flame device to BuildID: 20140903040203
2) Connect to a Data/Wifi Network
3) Select the E.me bar on the Homescreen
4) Search 'Social'
5) Select Facebook
6) Select the ellipses 
7) Select 'Add to Homescreen'
  
Actual:
The 'Add to Homescreen' page is not responding.
  
Expected: 
The 'Add to Homescreen' page is responding and user can add an app to the homescreen.
  
Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20140903040203
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: e58842c764dd
Version: 35.0a1 (2.2 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Notes:
Repro frequency: 100%
See attached: logcat

Comment 1

[Peter Bylenga [:PBylenga]]

Requesting a window.

Comment 2

[Josh Schmitt [Joshs]]

Issue does NOT occur on 2.1 Flame 319MB

Enviromental Variables:
----------------------------------------
Device: Flame 2.1
BuildID: 20140903000204
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: fb5e796da813
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 3

[Gregor Wagner [:gwagner]]

Can we get a logcat?

Comment 4

[Josh Schmitt [Joshs]]

Attachment: log.txt

I have uploaded a logcat, there was an error when filing while uploading, I have also uploaded a youtube video of the issue.

https://www.youtube.com/watch?v=0vtRTWU1Kpk

Comment 5

[Marcia Knous [:marcia]]

I see this when trying to add any bookmark to homescreen.

Gaia   52670853c17fc0d3d33065c667c0ce124c93b98f
SourceStamp 5e9826980be5
BuildID 20140903072057
Version 35.0a1
base: v123

Comment 6

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Bad functional regression that blocks smoke tests from passing.  I don't have a 2.2? flag to set it to.

Comment 7

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 967844 seems to have caused this issue.

Mozilla-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140902021513
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: 39a8d9b2b639
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140902025713
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: ea4cfd84e417
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last working gaia / First broken gecko - Issue DOES occur
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: ea4cfd84e417

First broken gaia / Last working gecko - Issue does NOT occur
Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c
Gecko: 39a8d9b2b639

Gecko Pushlog:  hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39a8d9b2b639&tochange=ea4cfd84e417

Comment 8

[Joshua Mitchell (Inactive)]

Possible Regression from Bug 967844? Can you take a look Robert?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I just tried the steps in comment #0 with Gecko acbdce59da2f (today) and Gaia 380d6a3f06438ee85e847585df662fd0e144777e (August 22 or thereabouts), and it seemed to work fine on my Flame.

I'll try a full update of my B2G build.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

And I just tried it with latest Gaia pull and it worked.

Maybe my steps to reproduce aren't quite right?

(In reply to Josh Schmitt [Joshs] from comment #0)
> Repro Steps:
> 1) Update a Flame device to BuildID: 20140903040203
> 2) Connect to a Data/Wifi Network
> 3) Select the E.me bar on the Homescreen
> 4) Search 'Social'
> 5) Select Facebook
> 6) Select the ellipses 

I'm not sure what this step is; I don't know what "the ellipses" are. Instead I do a long-press on the Facebook icon, get a window with "add to homescreen" and "cancel", and then I get the "Add link" screen with "Website name", "address", and an "Add to Home Screen" button like I see in the video, but I can click on that bugtton just fine.

Comment 11

[Amir Nissim (:amirn)]

Might be a regression from bug 1031084.
Cristian, can you take a look please?

Comment 12

[Cristian Rodriguez (:crdlc)]

It is not my regression, I reverted my patch locally and it still fails. I can see the "Add to home screen" view if I click again on ev.me field

(In reply to Amir Nissim (:amirn) from comment #11)
> Might be a regression from bug 1031084.
> Cristian, can you take a look please?

Comment 13

[Amir Nissim (:amirn)]

The correct component should be Gaia::Bookmark

Comment 14

[Cristian Rodriguez (:crdlc)]

I think that is Search or System because the contextmenu screen lives in system AFAIK

(In reply to Amir Nissim (:amirn) from comment #13)
> The correct component should be Gaia::Bookmark

Comment 15

[Cristian Rodriguez (:crdlc)]

I have seen the video, I misunderstood the STRs although I cannot reproduce it with latest master

Comment 16

[Joshua Mitchell (Inactive)]

Qa-Wanted tag to verify that this does not reproduce in the latest master

Comment 17

[Duane Dixon [:ddixon]]

Issue DOES occur on latest Nightly master build. 

I used the STR listed in comment 0. 

Actual Results: "Add to homescreen" page is unresponsive. 

Repro: 2/2 100%

Environmental Variables:
Device: Flame Master (2.2)
Build ID: 20140904040204
Gaia: 008026e932b64b4a70b9931c3da96986583bc8d4
Gecko: 776fa9cf70cd
Version: 35.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Comment 18

[Joshua Mitchell (Inactive)]

adding 2.2 flag based on comment 6 (flag was previously unavailable)

Comment 19

[Jason Smith [:jsmith]]

Rob - What device are you testing with?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Flame.

Whoever can reproduce this, try setting gDumpEventList to true in your build and then reproduce the bug. There should be some spew starting "Event handling --- " to logcat every time you try to press the button. That data would help us narrow down the bug a lot. If there is no such spew when you try to press the button, that would also be interesting.

Botond, seems like this could be related to APZC event handling, so maybe you should try to reproduce it.

Comment 21

[Jason Smith [:jsmith]]

No-Jun - When you into work tomorrow, can you try to reproduce this? If you can, then you show the reproduction to Botond?

Comment 22

[Botond Ballo [:botond]]

(In reply to Josh Schmitt [Joshs] from comment #0)
> 3) Select the E.me bar on the Homescreen

In case anyone else is as unfamiliar with Gaia terminology as I am: the "E.me bar" appears to be what's called the "rocketbar" in other bugs.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #20)
> Botond, seems like this could be related to APZC event handling, so maybe
> you should try to reproduce it.

I tried reproducing this on a Flame with today's trunk, and was unable to.

(The Keyboard did crash an awful number of times when activating it by clicking on the E.me bar from the homescreen before I could finally type, though... like bug 1059832, but rather than just crashing once, it crashed a few times).

Comment 23

[Botond Ballo [:botond]]

I had my patches for bug 1062437 applied when I was testing. I tried with them unapplied, and I could repro the issue, suggesting that this may be a duplicate.

To be sure, let's ask QA to retest this once bug 1062437 gets into a nightly.

Comment 24

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #23)
> I had my patches for bug 1062437 applied when I was testing. I tried with
> them unapplied, and I could repro the issue, suggesting that this may be a
> duplicate.

It's certainly plausible, as the underlying problem in bug 1062437 is a wrong APZC tree structure, and hit testing is done based on the APZC tree. Failure of hit testing can make a page appear nonresponsive.

Comment 25

[Jason Smith [:jsmith]]

[Blocking Requested - why for this release]:

Paul just confirmed this happens on 2.1 in the bug bash, so bumping this up to 2.1?

Comment 28

[Jason Smith [:jsmith]]

Marking qawanted to retest with bug 1062437 is included in the build.

Comment 29

[Gregor Wagner [:gwagner]]

(In reply to Jason Smith [:jsmith] from comment #25)
> [Blocking Requested - why for this release]:
> 
> Paul just confirmed this happens on 2.1 in the bug bash, so bumping this up
> to 2.1?

Hm this wasn't part of the 2.1 smoketest report from marcia today. does this only reproduce on certain devices?

Comment 30

[Cristian Rodriguez (:crdlc)]

Just to clarify:

* Add to home screen from Collections

It works fine

* Add to home screen from Search view

1) Long press an icon in search view
2) Click on "Add to home screen" button
3) The search view disappears and the home screen is displayed
4) Click on search field again the "Add to home screen" view appears and works fine

* Add to home screen from Browser

The "Add to home screen" view appears properly but it is unresponsive

So here we have two different bugs thought

Comment 31

[Cristian Rodriguez (:crdlc)]

Kevin, Dale, any idea why is bookmarking feature failing from search view? See comment 30. Thanks guys

Comment 32

[Dale Harvey (:daleharvey)]

From the browser I cant reproduce this, but from the search app I can see the problem, there looks to be something wrong with the way the grid is handling events, I can take this, if you can still reproduce the browser bug then I think it would be best to open a seperate bug.

Comment 33

[Cristian Rodriguez (:crdlc)]

I could reproduce it from the browser in a build 2.1 but I cannot reproduce it with master, at least I couldn't

Comment 34

[Dale Harvey (:daleharvey)]

mine was in master, I will take a look at this one, then check and file the other one if needed

Comment 35

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #29)
> (In reply to Jason Smith [:jsmith] from comment #25)
> > [Blocking Requested - why for this release]:
> > 
> > Paul just confirmed this happens on 2.1 in the bug bash, so bumping this up
> > to 2.1?
> 
> Hm this wasn't part of the 2.1 smoketest report from marcia today. does this
> only reproduce on certain devices?

Probably because the smoketest is done against the first build of the day (generated at 4am), where as Paul was likely testing this on the second build of the day (generated at 4pm).

Comment 36

[Jason Smith [:jsmith]]

(In reply to Cristian Rodriguez (:crdlc) from comment #33)
> I could reproduce it from the browser in a build 2.1 but I cannot reproduce
> it with master, at least I couldn't

That probably confirms that bug 1062437 fixed this bug. I'll wait for qawanted to confirm this.

(In reply to Dale Harvey (:daleharvey) from comment #32)
> From the browser I cant reproduce this, but from the search app I can see
> the problem, there looks to be something wrong with the way the grid is
> handling events, I can take this, if you can still reproduce the browser bug
> then I think it would be best to open a seperate bug.

Does your build include the patch from bug 1062437? If so, then we likely have another problem here in addition to bug 1062437.

Comment 37

[Gregor Wagner [:gwagner]]

Kevin will re-test.

Comment 39

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #28)
> Marking qawanted to retest with bug 1062437 is included in the build.

The fix for bug 1062437 landed this morning at 8:43, and our latest tinderbox central build is built at 3AM this morning (20140905031309). The bug still occurs in build 20140905031309. We will re-test when we have a build available containing the fix.

Comment 40

[Kevin Grandon :kgrandon]

I tested with the fix from bug 1062437 in master and this is now resolved. Let's make sure that one gets uplifted. Not sure what the proper resolution is here, but just going to mark as worksforme to try to avoid any uplift queries.

Comment 41

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #40)
> I tested with the fix from bug 1062437 in master and this is now resolved.
> Let's make sure that one gets uplifted. Not sure what the proper resolution
> is here, but just going to mark as worksforme to try to avoid any uplift
> queries.

Marking fixed via bug 1062437. I've asked bbajaj to approve bug 1062437 for uplift.

Comment 43

[Roland Kunkel [:RolandK]]

Verified as fixed for latest 2.2 Flame build:

Enviromental Variables:
----------------------------------------
Device: Flame 2.2 Master
BuildID: 20140908040204
Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d
Gecko: 8927689859
Version: 35.0a1 (2.2 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Following the STRs listed in comment 0, The 'Add to Homescreen' page is responding and the user can add apps to the homescreen.

Comment 44

[Botond Ballo [:botond]]

I believe Gecko 33 is unaffected because the regressing bug (multi-layer-apz was only uplifted to 34).

Comment 45

[Roland Kunkel [:RolandK]]

Verified as fixed for latest 2.1 Flame build:

Enviromental Variables:
----------------------------------------
Device: Flame 2.1
BuildID: 20140909000204
Gaia: c7b55ed3be126b1f5f3d9cdd0277c365a6652d29
Gecko: 956b152e6d21
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Following the STRs listed in comment 0, The 'Add to Homescreen' page is responding and the user can add apps to the homescreen.

Comment 46

[Kevin Grandon :kgrandon]

Bug 1062437 came with a test for this.