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

VERIFIED FIXED in 2.2 S9 (3apr)

Status

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: hcheng, Assigned: daleharvey)

Tracking

({regression})

unspecified
2.2 S9 (3apr)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [systemsfe])

Attachments

(1 attachment)

* 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
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.
blocking-b2g: --- → 2.2?
Flags: needinfo?(dale)
Keywords: regression
Whiteboard: [systemsfe]
(Assignee)

Comment 2

4 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
Flags: needinfo?(timdream)
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...
Flags: needinfo?(timdream) → needinfo?(hcheng)
On v2.2, the caret is still flashing when scrolling which is not on 2.0.
Flags: needinfo?(hcheng)
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.
(Assignee)

Comment 6

4 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.
Flags: needinfo?(dale)
(Assignee)

Comment 7

4 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?
Flags: needinfo?(timdream)
blocking-b2g: 2.2? → 2.2+
Keywords: qawanted
QA Contact: ychung
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.
Duplicate of this bug: 1147166
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
Can you take a look here?
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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").
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
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.
Flags: needinfo?(timdream)
(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?
Flags: needinfo?(dale)
Component: Gaia::Search → Gaia::System
(Assignee)

Comment 15

4 years ago
Yup will do
Assignee: nobody → dale
Flags: needinfo?(dale)
(Assignee)

Comment 17

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

Just checking in with Tim that this is a good idea
Attachment #8586717 - Flags: review?(kgrandon)
Attachment #8586717 - Flags: feedback?(timdream)
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!
Attachment #8586717 - Flags: review?(kgrandon) → review+
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.
Attachment #8586717 - Flags: feedback?(timdream) → feedback+
(Assignee)

Comment 20

4 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
(Assignee)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 21

4 years ago
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]:
Attachment #8586717 - Flags: approval-gaia-v2.2?
So this is indeed in the Search app...
Component: Gaia::System → Gaia::Search
Attachment #8586717 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(dale)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][failed-verification]
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
(Assignee)

Comment 25

4 years ago
Filed a follow up https://bugzilla.mozilla.org/show_bug.cgi?id=1151822
Flags: needinfo?(dale)
Depends on: 1151822
This bug has been successfully verified in https://bugzilla.mozilla.org/show_bug.cgi?id=1151822#c5.
So clear "verifyme" and set as "VERIFIED".
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.