1027282 - [Rocketbar] If an overlay prompt interrupts a search, the keyboard disappears forcing you to refocus on the rocketbar

Status: VERIFIED FIXED

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

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

1. turn on bluetooth on device
2. tap in the rocketbar
3. type in "Something" without hitting return
4. from a different device/computer, try to do bluetooth pairing

Expected: overlay overlays on top of the current search and doesn't interrupt
Actual: overlay interrupts and cancels the search.

Note: 
1. I'm not 100 % sure of the expected; need ux help, it does seem odd
2. This is with any prompt, geolocation, etc. bluetooth is the easiest to repro

Gaia      83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/55679dc2e72b
BuildID   20140618000202
Version   32.0a2
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014
Flame

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hey UX team, I wasn't sure of the expected.  Could you take a look?

Comment 2

[Jason Smith [:jsmith]]

This problem is actually more apparent when you first try to use rocketbar, since you get a geolocation prompt on first use & are forced to refocus the search bar. Definitely annoying.

Need UX input if this is annoying enough to block or not.

Comment 3

[Stephany Wilkes]

I've run into this. It's really annoying (and, as we saw in user testing, the geolocation prompt can actually completely derail people from what they set out to do). I would like to block since we've seen it can get in the way of the user completing the search they set out to do, but defer to Francis.

Comment 4

[Francis Djabri [:djabber]]

I would say this is a blocker since it messed up the first time experience.

Comment 5

[Dale Harvey (:daleharvey)]

The real platform fix for this is difficult, but we "should" be able to handle it in the search app manually and have a reasonable workaround

Comment 6

[Dale Harvey (:daleharvey)]

ok the workaround doesnt work so far, modal dialogs dont trigger visibility or focus events (on the document)

Alive you got any idea about a good fix for this? will keep looking

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Dale Harvey (:daleharvey) from comment #6)
> ok the workaround doesnt work so far, modal dialogs dont trigger visibility
> or focus events (on the document)
> 
> Alive you got any idea about a good fix for this? will keep looking

Does it help if we:
* Re-focus the search window iframe after permission dialog hide
* Re-focus the search window iframe after attention window hide

I think refocus is the best gaia could do.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

So we have two issues here, one is for permission dialog and one is for attention screen.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

I just noticed that gaia has nothing to do using iframe.focus(). This doesn't trigger the iframe to refocus the input.

The only way for now is to do evt.preventDefault when user clicks the buttons of permission prompt and other UI. But this is a big work. We cannot do this for every app in the world.

I'd rather to think "resume the focus in iframe when we back to it" is a new feature request, so this bug shouldn't be blocker any way.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #9)
> I'd rather to think "resume the focus in iframe when we back to it" is a new
> feature request, so this bug shouldn't be blocker any way.

I don't think our partners are going to take this release if we don't fix this. This is a poor first time experience of the rocketbar right now with this bug.

Comment 11

[Dale Harvey (:daleharvey)]

Alive, for the workaround, I was wondering if iframe.focus() would at the least trigger document.on('focus' and we could handle it manually inside the search app, I think ideally each frame should keep track of their own focus and restore it (automatically)

This also may be an issue that the search app is not part of the normal app window manager

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Dale Harvey (:daleharvey) from comment #11)
> Alive, for the workaround, I was wondering if iframe.focus() would at the
> least trigger document.on('focus' and we could handle it manually inside the
> search app, I think ideally each frame should keep track of their own focus
> and restore it (automatically)
> 

Basically I agree that focus should retrigger, but the problem is gecko just drops the focus info when user touches some other UI outside the iframe. Rudy told me this(focus drop) and this is there for a long time.

I dare not to say this is correct or not because if we switch app quickly, the keyboard will be up/down quickly due to this 'feature'.

Comment 13

[Jason Smith [:jsmith]]

One way we could get around this bug is by doing what bug 1014410 does for certified apps.

Antonio & Paul - Is there any reason why we shouldn't enable what bug 1014410 describes in certified apps?

Comment 14

[Dale Harvey (:daleharvey)]

I have a simple patch for this

Comment 15

[Dale Harvey (:daleharvey)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/20829

I think this is a fairly safe and simple solution

I found another bug that geolocation dialog is shown twice, however its unrelated to my patch, filed and will investigate @ https://bugzilla.mozilla.org/show_bug.cgi?id=1028432

Comment 16

[Jason Smith [:jsmith]]

When bbajaj & I talked in triage, if there's feasibility to fix this in a non-risky way, then we should block on it. On that regard, I'm moving this to 2.0+.

Comment 17

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to Jason Smith [:jsmith] from comment #13)
> One way we could get around this bug is by doing what bug 1014410 does for
> certified apps.
> 
> Antonio & Paul - Is there any reason why we shouldn't enable what bug
> 1014410 describes in certified apps?

Sorry for the late answer here. Bug 1014410 doesn't actually change any prompt explicit permission into implicit. What it does is auto-grant (and remember) the permission to preinstalled apps *only* if the same permission for a certified app is implicit. And since geolocation is explicit for certified also, a privileged app that requested geolocation would still show the prompt (and in fact the unit test for that bug tests that).

In other words, it wouldn't have helped here.

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8443768 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20829

r=me if the fixes the problem.

Comment 19

[Dale Harvey (:daleharvey)]

https://github.com/mozilla-b2g/gaia/commit/c20adfa4a90a5ea5c1f4f18ca2f7a93b6273c49e

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b884a3b716b7

Comment 21

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/ce8b97ca7d75289a48c7b3dbb91648b0e03c8c28

Comment 22

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Geolocation will keep you in the search with the focus on the bar; bluetooth will kick you out of the search completely and back to homescreen.  Tapping on the Rocketbar will allow you to continue your search term.

Gaia      57da30f405ba37a5d4844f32bb292271b81faee2
Gecko     https://hg.mozilla.org/mozilla-central/rev/a19e0434ea52
BuildID   20140625040202
Version   33.0a1
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
Flame

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Verified on 2.0:

Gaia      de77f794db22a45f9d575de2c6e266a30a50de3b
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/79712bd7b60d
BuildID   20140625000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
Flame