Hermes Cheng (inactive after July 27, 2015) Reporter
	Description • 9 years ago

* 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

	Hermes Cheng (inactive after July 27, 2015) Reporter
	Comment 1 • 9 years ago

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.

	Dale Harvey (:daleharvey) Assignee
	Comment 2 • 9 years ago

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

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 3 • 9 years ago

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...

	Hermes Cheng (inactive after July 27, 2015) Reporter
	Comment 4 • 9 years ago

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

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 5 • 9 years ago

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.

	Dale Harvey (:daleharvey) Assignee
	Comment 6 • 9 years ago

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.

	Dale Harvey (:daleharvey) Assignee
	Comment 7 • 9 years ago

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?

	Martijn Wargers (dead)
	Comment 8 • 9 years ago

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.

	Yeojin Chung [:YeojinC]
	Comment 10 • 9 years ago

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

	Gregor Wagner [:gwagner]
	Comment 11 • 9 years ago

Can you take a look here?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 12 • 9 years ago

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").

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 13 • 9 years ago

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.

	Gregor Wagner [:gwagner]
	Comment 14 • 9 years ago

(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?

	Dale Harvey (:daleharvey) Assignee
	Comment 15 • 9 years ago

Yup will do

	Dale Harvey (:daleharvey) Assignee
	Comment 17 • 9 years ago

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

Just checking in with Tim that this is a good idea

	Kevin Grandon :kgrandon
	Comment 18 • 9 years ago

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

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

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 19 • 9 years ago

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

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

	Dale Harvey (:daleharvey) Assignee
	Comment 20 • 9 years ago

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

	Dale Harvey (:daleharvey) Assignee
	Comment 21 • 9 years ago

Comment on attachment 8586717 [details]
[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]:

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 22 • 9 years ago

So this is indeed in the Search app...

	Ryan VanderMeulen [:RyanVM]
	Comment 23 • 9 years ago

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

	Pi Wei Cheng [:piwei] (inactive)
	Comment 24 • 9 years ago

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

	Dale Harvey (:daleharvey) Assignee
	Comment 25 • 9 years ago

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

	Shally Li（leave from Mozilla）
	Comment 26 • 9 years ago

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