594918 - dismiss vkb as a user starts to pan the awesomelist

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Madhava Enros [:madhava]]

In current builds, when the user taps on the titlebar to bring up the awesomescreen, the url field is focused and the vkb comes up.  Right now, you have to tap on something (which blurs the input field) to dismiss the keyboard.  Instead, the keyboard should go away as soon as the user starts to pan or flick the awesomelist.  By the time he or she is panning through the list, he or she is clearly interested in seeing more results.

Tapping on the field again should bring the keyboard back up.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

If we blur the text field, we would lose any context like selected text or caret position. I assume that is OK.

Comment 2

[Madhava Enros [:madhava]]

Is there a way to not lose those things?  A good example to follow is the search mode of the Android Market - they seem to preserve carat position.  In fact, the field remains (at least visually) focused.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

As far as I know this is the _only_ situation we want to hide the vkbd when panning a list. Correct?

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

I think that's right. It's certainly not the case that when the user has focused a text field or list in content that panning should dismiss the VKD (see bug 592330 comment 5)

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #3)
> As far as I know this is the _only_ situation we want to hide the vkbd when
> panning a list. Correct?

I think we also want to dismiss it while panning any of the awesome screen once bug 596614 will land. With the patch from there we will be able to have the VKB without changing the current awesomescreen, so it will be possible to have a VKB in the bookmarks awesome panel for example.

What do you guys think?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Vivien - did bug 596614 fix this bug too?

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #6)
> Vivien - did bug 596614 fix this bug too?

No it won't but this one is easy to fix. I think we juts need to add a PanBegin event listener on the list and blur the focused element when it starts

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 482204 [details] [diff] [review]
Patch

(In reply to comment #8)
> Created attachment 482204 [details] [diff] [review]
> Patch

hmm, this one has some bad side effects, unrequesting review

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 482204 [details] [diff] [review]
Patch

Re-requesting review since the side effects came from one of my other patch

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 482204 [details] [diff] [review]
Patch

A comment saying that setting this._edit.readOnly = true, will close the awesomebar might be helpful here too.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

ready to land?

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

This one is rebased on top of bug 609619

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

http://hg.mozilla.org/mobile-browser/rev/a204590a2af8

Comment 15

[Aakash Desai [:aakashd]]

verified FIXED on builds (nexus one and vibrant):
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101015 Namoroka/4.0b8pre Fennec/4.0b2pre