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
Hey UX team, I wasn't sure of the expected. Could you take a look?
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.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?]
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.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
I would say this is a blocker since it messed up the first time experience.
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?] → [VH-FL-blocking-][VH-FC-blocking+]
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
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
(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.
So we have two issues here, one is for permission dialog and one is for attention screen.
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.
Assignee: alive → nobody
(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.
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
(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'.
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?
I have a simple patch for this
Assignee: nobody → dale
Created attachment 8443768 [details] [review] 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
Attachment #8443768 - Flags: review?(alive)
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+.
blocking-b2g: 2.0? → 2.0+
(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 on attachment 8443768 [details] [review] https://github.com/mozilla-b2g/gaia/pull/20829 r=me if the fixes the problem.
Attachment #8443768 - Flags: review?(alive) → review+
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
status-b2g-v2.0: affected → fixed
status-b2g-v2.1: --- → fixed
Target Milestone: --- → 2.0 S5 (4july)
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
Status: RESOLVED → VERIFIED
status-b2g-v2.1: fixed → verified
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
status-b2g-v2.0: fixed → verified
You need to log in before you can comment on or make changes to this bug.