1149435 - [Search] keyboard does not disappear after user starts to scroll the results

Status: VERIFIED FIXED

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

Description

[Hermes Cheng (inactive after July 27, 2015)]

* Description:
When the user starts to scroll the search result list, the keyboard should disappear

* STR:
1. tap rocketbar at Homescreen and start input something
2. after result list is shown, start to scroll down

* Expected result:
keyboard disappear

* Actual result:
keyboard is still there

Comment 1

[Hermes Cheng (inactive after July 27, 2015)]

I think this is a regression which does not exist on 2.0. It also failed a test case (https://moztrap.mozilla.org/manage/cases/?filter-id=13923), so nom a 2.2 blocker.

Comment 2

[Dale Harvey (:daleharvey)]

I will take a look, but pinging a keyboard peer in case since I dont think theres any changes to search app that should affect this

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hermes, does the caret still flashing on the input when you start scrolling on v2.2 build? How about v2.0?

Might be caused by APZ changes I think...

Comment 4

[Hermes Cheng (inactive after July 27, 2015)]

On v2.2, the caret is still flashing when scrolling which is not on 2.0.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Dale, are you sure there is no code changes in Search app that remove the removal of the focus or cancel the focus change (from touch/mousedown events)? If not we would really need a regression window to find the identify the regressed bug.

Comment 6

[Dale Harvey (:daleharvey)]

The only focus code is to refocus the rocketbar (which is in the system app) when there is a element clicked on in the search app, its only bound to a 'click' on that element so cant effect the rest of the app. There are no other mousedown / touch events handled.

Comment 7

[Dale Harvey (:daleharvey)]

Thats probably worth mentioning, the focus in this case is inside the system app, not the search app which is the one being scrolled.

Also, isnt it the default behaviour to not discard the keyboard when scrolling? that is what happens with web content, wouldnt we need to manually unfocus the input?

Comment 8

[Martijn Wargers (dead)]

Could this also be a regression from the fix from bug 1075670? That one is backed out (currently on inbound). We might want to wait until it gets backed out on mozilla-central to see if it is fixed by that.

Comment 10

[Yeojin Chung [:YeojinC]]

Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150201170935
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: 231a8c61b49f
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150201174135
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: bcefc7d8d885
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: bcefc7d8d885

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: 231a8c61b49f

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=231a8c61b49f&tochange=bcefc7d8d885

possibly caused by bug 950934

Comment 11

[Gregor Wagner [:gwagner]]

Can you take a look here?

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Yes, I was aware that this change was introduced when bug 950934 landed. However as Dale says in comment 7, this just makes the behaviour consistent with how the keyboard dismisses everywhere else, i.e. if you are in the browser and the keyboard is up, you can scroll the content without the keyboard disappearing. I'm not convinced this needs "fixing" on the platform side unless somebody has a strong argument (i.e. not "that's the way it was before").

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Per comment 12, this is a valid follow-up in Gaia to the platform change then.

We need to better at tracking things like these.

Comment 14

[Gregor Wagner [:gwagner]]

(In reply to Dale Harvey (:daleharvey) from comment #7)
> Thats probably worth mentioning, the focus in this case is inside the system
> app, not the search app which is the one being scrolled.
> 
> Also, isnt it the default behaviour to not discard the keyboard when
> scrolling? that is what happens with web content, wouldnt we need to
> manually unfocus the input?

Can you take care of this?

Comment 15

[Dale Harvey (:daleharvey)]

Yup will do

Comment 16

[GitHub Autolander Bot]

Attachment: [gaia] daleharvey:1149435 > mozilla-b2g:master

Comment 17

[Dale Harvey (:daleharvey)]

Comment on attachment 8586717 [details] [review]
[gaia] daleharvey:1149435 > mozilla-b2g:master

Just checking in with Tim that this is a good idea

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8586717 [details] [review]
[gaia] daleharvey:1149435 > mozilla-b2g:master

The code seems fine to me, but please wait for Tim's feedback before landing. Thanks!

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8586717 [details] [review]
[gaia] daleharvey:1149435 > mozilla-b2g:master

Should be |document.body.focus()| or |input.blur()| but that's really trivial.

Comment 20

[Dale Harvey (:daleharvey)]

Cheers I switched to document.body.focus (we dont actually have a reference to the input, its in the system app)

Green @ https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=55e5376c1ec183f7e7a245a7e321b9d6c2f04497
Landed in https://github.com/mozilla-b2g/gaia/commit/864e60fd182528de9e3eba1d8153667b2caeba6f

Comment 21

[Dale Harvey (:daleharvey)]

Comment on attachment 8586717 [details] [review]
[gaia] daleharvey:1149435 > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): https://bugzilla.mozilla.org/show_bug.cgi?id=950934
[User impact] if declined: Poor behaviour for search app scrolling
[Testing completed]: Unit tests added and manual verification
[Risk to taking this patch] (and alternatives if risky): Little risk
[String changes made]:

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

So this is indeed in the Search app...

Comment 23

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/22d344cbbde90d1d03b4167726f49f7f246b5616

Comment 24

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

This issue has failed verification. Scrolling on rocketbar search results does NOT dismiss the keyboard. (I've verified that the central build contains the fix at comment 20)

See video:
https://www.youtube.com/watch?v=sy71Xk4CCGg

Failed verification on the following builds:
Device: Flame 3.0 Master(KK, 319MB, full flash)
BuildID: 20150406010204
Gaia: ef61ebbe5de8c2c9fc2a8f74a12455044c3b82e9
Gecko: 4fe763cbe196
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Device: Flame 2.2 (KK, 319MB, full flash)
BuildID: 20150406002503
Gaia: a6351e1197d54f8624523c2db9ba1418f2aa046f
Gecko: c3335a5d3063
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 25

[Dale Harvey (:daleharvey)]

Filed a follow up https://bugzilla.mozilla.org/show_bug.cgi?id=1151822

Comment 26

[Shally Li（leave from Mozilla）]

This bug has been successfully verified in https://bugzilla.mozilla.org/show_bug.cgi?id=1151822#c5.
So clear "verifyme" and set as "VERIFIED".