805586 - [keyboard] keyboard needs a 'hide keyboard' button (main tracking bug)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Keyboard, defect, P1)

Description

[Olivier Yiptong [:oyiptong]]

the keyboard needs a 'hide keyboard' button when it has erroneously been launch... e.g. by fat-fingering.

Comment 1

[Olivier Yiptong [:oyiptong]]

phone id: 14321

Comment 2

[David Scravaglieri [:scravag]]

There is a workaround, just hit the content

Comment 3

[Hubert Figuiere [:hub]]

This is pretty bad as a work around. Seriously.

Comment 4

[Yuan Xulei [:yxl] (Leave from May 18)]

We may need UX input on this issue.
cc Rafael.

Comment 5

[Luke Crouch [:groovecoder]]

Tapping the content is not a workaround when most of the content is links. ><

Comment 6

[Hubert Figuiere [:hub]]

Android use the "back" button - that we don't have - to do that.

Comment 7

[Matt Woodrow (:mattwoodrow)]

This doesn't only affect you when the keyboard has accidentally been launched, I have this issue when trying to login on facebook.com.

When you enter your email address, the onscreen keyboard covers the password field, almost all the visible content is a link, and the enter key will try log me in without having entered my password.

Comment 8

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

On small screens, keyboard covers most of the screen, being able to hide is more than needed most of the times.

Comment 9

[Rafael Rebolleda]

The fact that the keyboard sits on top of the focused text field is something that should be prevented, regardless of whether we can (or should) hide the keyboard manually. Those text fields should automatically scroll to the visible portion of the screen and should be treated as a different issue.

I'm reluctant to add a key to hide the keyboard. We already don't have space for other useful keys (such as "next" for forms), and hiding the keyboard is not a feature in itself but rather a "panic" key when other things haven't been properly architected.

I'd vouch for a swipe/drag down anywhere on the keyboard to simply hide it. Plus there's also tapping outside the keyboard as mentioned previously, which should work just fine in most cases.

Comment 10

[Olivier Yiptong [:oyiptong]]

It needs to be something intuitive. the problem with tapping outside the keyboard is that there is no "affordance" for it. That is the problem with gestures for hiding.

It becomes a power-user feature, leaving most users confused.

I do agree that we don't know if a dedicated "hide" button *may* not be the best solution, but how do we find if that is true.

How do we find the best set of buttons to include? It may turn out that the hide button has more reason to be there than the "form next", in terms of UX.

Thinking out of the box, why can't the "hide" button be found on top of the keyboard? It doesn't even need to be a button in that case, just an indication that tapping in that area will hide the keyboard.

I do agree that the keyboard should not sit on top of the text field. In fact, the viewport should zoom out a bit, to allow the user to see more of the screen.

Comment 11

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

In in favour of a small tiny bar/area/arrow/circle at the top of the keyboard to tap down the keyboard as you tap up the notification panel to hide.

Comment 12

[Walter Chen[:ypwalter][:wachen]]

I think this is a good to have! Still need UX input.

Comment 13

[Stephany Wilkes]

Assigning from general UX identity to Francis, since this is keyboard themed.

Comment 14

[Leo]

In Marketplace,
when you press search,keyboard appears
And there is no cancel button to deselect search bar and hide keyboard
And you cannot tap page because it has links to Marketplace apps everywhere.
This is place where tapping on page to hide keyboard fails.
It needs to have one other way to hide the keyboard.

Comment 17

[Walter Chen[:ypwalter][:wachen]]

There are way too many dup bugs for this one...

Comment 18

[Mounir Lamouri (:mounir)]

How does it work with iOS and Android devices with only one button?

I tried on an iPhone and I wasn't able to find a "Hide" button in most keyboards that appeared.

Comment 19

[Hubert Figuiere [:hub]]

iPad has it. Strangely iPhone doesn't seem to (I don't have an iPhone)

Android always have more than one button. They can be "software" but it always have the back button in that case. It is mandatory.

Comment 20

[Yuan Xulei [:yxl] (Leave from May 18)]

(In reply to Mounir Lamouri (:mounir) from comment #18)
> How does it work with iOS and Android devices with only one button?
> 
> I tried on an iPhone and I wasn't able to find a "Hide" button in most
> keyboards that appeared.
iPhone doesn't have a "Hide" button, but the keyboard of iPhone 5 (or above) could be hidden by swiping the screen downward.

Comment 21

[William Hsu [:whsu]]

Android phone had a "Hide" button on the lower left corner.
As attachment. Thanks.

Comment 22

[William Hsu [:whsu]]

Attachment: Android Keyboard layout

Comment 23

[Leo]

How about using the home button to hide the keyboard, if we are displaying the keyboard?

Comment 24

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi,

my 2 cents:

[Home button]
AFAIK, pressing "Home" button will also make you get out of the current app, which is the preferred behavior. 
That is to say, keyboard app should not block "Home" button, it should do one single thing to the user, which is (obviously) Back to Home screen.

[Swipe down]
I have not verified that this is implemented on iPhone 5 (though I did check this with iPhone 4S with iOS 6 but did not see it), but I think this is not what we want.
When you touch one key, and move to its bottom, it should let the user switch to another key underneath, which is the current behavior.
I don't see the possibility to implement "swipe down the keyboard" without canceling the above behavior.

Thanks for the input.

Comment 25

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

+ni Neo to see if he can provide some insight here.

Comment 26

[Yuan Xulei [:yxl] (Leave from May 18)]

(In reply to Rudy Lu [:rudyl] from comment #24)
> [Swipe down]
> I have not verified that this is implemented on iPhone 5 (though I did check
> this with iPhone 4S with iOS 6 but did not see it), but I think this is not
> what we want.
> When you touch one key, and move to its bottom, it should let the user
> switch to another key underneath, which is the current behavior.
> I don't see the possibility to implement "swipe down the keyboard" without
> canceling the above behavior.
> 

Not swiping down the keyboard, but the content above the keyboard on iPhone(with iOS 5 or above). It is a bit strange that only if the content on screen is scrollable, you can swipe it down to hide the keyboard. I can reproduce with the following steps(iPhone with iOS 6.0):
1. Launch "Messages"
2. Open any received message
3. Select reply box to show the keyboard
4. Swipe the message above the reply box to hide the keyboard.

There is a movie about it: http://www.youtube.com/watch?v=iIBt-oeRiAo

Comment 27

[Yuan Xulei [:yxl] (Leave from May 18)]

Attachment: Hide button of the Android Sogou IME

Another example of the "Hide" button on Android. It is the most popular Chinese Pinyin IME used in China mainland and has a small "Hide" button on the top right corner of the keyboard.

Comment 28

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Yuan,

Thanks for the info.
Yes, that reminds me of the special UX design in iOS message app, which I saw it before but did not think of it when you mentioned that.
However, that is not for every app, right? Because I tried other app, like "Note" app or LINE app, etc, but did not see similar behavior there.

Comment 29

[Francis Djabri [:djabber]]

Attachment: Scrim

I'm inclined to agree with Rafael that adding an extra button to the keyboard is not the best solution to this problem. 

However, I also agree that using a swipe down on the keyboard isn't an obvious enough method for dismissing the keyboard. In the particular case of the Marketplace app, I feel like a better approach would be to put up a semi-transparent scrim over the content area to make it more apparent that tapping on the content area will dismiss the keyboard without activating an item beneath - please see the attachment. Tapping on this area should dismiss the keyboard only and not activate any links beneath.

Comment 30

[Francis Djabri [:djabber]]

Note: for comment 29 above, tapping on the scrim should also make the search field lose focus.

Comment 31

[Stephany Wilkes]

Per Francis' suggestion in comments 29 and 30, assigning to VxD to provide guidance on the scrim that Francis provided a mock for. Please advise and/or reassign to advise on existing assets, color, opacity, etc. Thanks!

Comment 32

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Attachment: Top arrow to hide

As I commented, I'm in favour of a small tiny bar/area/arrow/circle on top of the keyboard to tap down the keyboard as you tap up the notification panel to hide. This doesn't add a new button on the keyboard.

I made a quick draw to illustrate it.

Comment 33

[Francis Djabri [:djabber]]

(In reply to Rubén Martín [:Nukeador] from comment #32)
> Created attachment 760630 [details]
> Top arrow to hide
> 
> As I commented, I'm in favour of a small tiny bar/area/arrow/circle on top
> of the keyboard to tap down the keyboard as you tap up the notification
> panel to hide. This doesn't add a new button on the keyboard.
> 
> I made a quick draw to illustrate it.

This is still a new button - even though it may not occupy the main space of the keyboard, it takes space away from the remaining content area. Furthermore, adding extra buttons and controls increases complexity and clutter.

Comment 34

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Uhm, you are right about the content area... then probably a swipe down content pointed out in comment 26 it's the best idea, but with an overlay tip about it first time you use the keyboard.

Comment 35

[Yuan Xulei [:yxl] (Leave from May 18)]

How about the solution of comment 22. Do we really need such a long space button. Could we make it shorter and give some space for a hide button?

Comment 36

[Francis Djabri [:djabber]]

(In reply to Rubén Martín [:Nukeador] from comment #34)
> Uhm, you are right about the content area... then probably a swipe down
> content pointed out in comment 26 it's the best idea, but with an overlay
> tip about it first time you use the keyboard.

I'm not convinced people actually read, understand or remember these scripts. It just causes people to think, which is not where we want to go with the experience.

Comment 37

[Francis Djabri [:djabber]]

(In reply to Yuan Xulei [:yxl] from comment #35)
> How about the solution of comment 22. Do we really need such a long space
> button. Could we make it shorter and give some space for a hide button?

The space button is used very frequently, more than any other key. There are big gains in having it large and easily tappable - these benefits far outweigh the benefits of a hide key IMHO.

Comment 38

[Francis Djabri [:djabber]]

Attachment: Search field as filter

I'd also like to clarify that I'm not suggesting that the scrim should be shown every time the keyboard is shown. But in this particular case of the Marketplace app it makes sense, or in other cases where the content area is filled with tappable - for example, in cases where the search field is being used as a filter within a list. See the attachment for details.

Comment 39

[Josh Carpenter [:jcarpenter]]

(In reply to Francis Djabri [:djabber] from comment #29)
> Created attachment 760617 [details]
> Scrim
> 
> 
> I'm inclined to agree with Rafael that adding an extra button to the
> keyboard is not the best solution to this problem. 
> 
> However, I also agree that using a swipe down on the keyboard isn't an
> obvious enough method for dismissing the keyboard. In the particular case of
> the Marketplace app, I feel like a better approach would be to put up a
> semi-transparent scrim over the content area to make it more apparent that
> tapping on the content area will dismiss the keyboard without activating an
> item beneath - please see the attachment. Tapping on this area should
> dismiss the keyboard only and not activate any links beneath.

+1. This is unquestionably the way to go. Trying to add additional buttons to a phone keyboard is a non-starter, for the reasons already cited.

Comment 40

[Patryk Adamczyk [:patryk] UX]

It should probably be anchored to a corner, due to our large margins and ergonomics, the left corner makes most sense.

Eric can you attach a mock up.

Comment 41

[Patryk Adamczyk [:patryk] UX]

I feel the issue with the scrim work when you're filling out long forms? it wouldn't exist really.

Comment 42

[Chris Lee [:clee]]

Given the arguments of a small screen, the keyboard covering input fields (which is a separate bug we should address), and the fact that tapping content does not seems acceptable to many people, comment 29 seems to be the most optimal approach.  

I would like to see this addressed given the usability of the keyboard is near the top of the priorities.  With a leo+, I see this as confirmation from our partner that they are willing to accept the risk in this change.  Thanks.

Comment 43

[Stephany Wilkes]

Thank you, Chris!

Comment 44

[Wayne Chang [:wchang]]

Reviewing this with Leo, to re-confirm on leo+ status in 24 hours.
ni?myself to update

Comment 45

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

The implementation semi-transparent scrim as Comment 29 suggested would live in the app itself instead of the Gaia keyboard component.
This is because Gaia keyboard can not know when/where to show the scrim around the input field.

ni to Chris to ask for his opinion to do this in marketplace.

Comment 46

[Neo Hsieh [:neo]]

Hi Everyone, I just discussed this issue with Rudy face to face. 
I think we can try to implement swipe down behavior of hiding keyboard. That's smooth in dynamic quality design. When user wants to hide the keyboard, just need one finger to swipe down. 

We will provide FTU image at first time user launch keyboard. Let Rudy try to implement this way first. How do you think ?

Comment 47

[Yuan Xulei [:yxl] (Leave from May 18)]

Greate! Rudy, please feel free to take the bug if you need.
FYI, the keyboard app can call mozKeyboard.removeFoucs() to hide the keyboard.
If you need any support for gecko, please let me know.

Comment 48

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10637

Pointer to Github pull-request

Comment 49

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 767705 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10637

Hi David,

This is WIP, since sometimes I cannot get "swipe" event triggered.

An easy way to reproduce this situation is,
 1. long press the "keyboard switching" key to move around the keyboard layout menu.
 2. After that, cannot receive swipe event from GestureDetector.
    (I have seen that this might be because we would get mousedown event in GD, to make FSM go into wrong state ??)

I am still investigating the root cause and evaluate if I have to write my own swipe gesture detector.

Thanks.

Comment 50

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Clear the ni flag for :cvan since we are going the keyboard app way to fix this.

Comment 51

[David Flanagan [:djf]]

Rudy,

I don't see anything obviously wrong with the code. Gesture detector was not designed to be used with code that is doing a lot of its own event handling, so I'm not terribly surprised that you're having trouble.

Gesture detector seems like a lot of code to import for this one gesture. I'd think that you could add a bit of code in onTouchStart (or startPress) and some more in onTouchEnd (or endPress) to compare the start and end points and times of a single touch.  Right now if I start at the top of the keyboard and swipe down I usually end up entering a space, which seems like a bug anyway.  So maybe movePress() should be modified to only move the target element if the gesture is slow enough or if the new key is close enough to the original.

Comment 52

[David Flanagan [:djf]]

Comment on attachment 767705 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10637

My feedback is in the comment above.

I'm setting feedback+ here because I like the idea of using a swipe gesture to dismiss the keyboard.  But as I've noted above, I don't recommend trying to use gesture_detector.js for that purpose.

Comment 53

[Francis Djabri [:djabber]]

(In reply to Neo Hsieh from comment #46)
> Hi Everyone, I just discussed this issue with Rudy face to face. 
> I think we can try to implement swipe down behavior of hiding keyboard.
> That's smooth in dynamic quality design. When user wants to hide the
> keyboard, just need one finger to swipe down. 
> 
> We will provide FTU image at first time user launch keyboard. Let Rudy try
> to implement this way first. How do you think ?

I'm not totally against using a swipe to dismiss the keyboard, but I do have some concerns. 

Firstly, using swipe to dismiss is a hidden feature, even if we provide some information on FTU (evidence suggests that the majority of users skip past these FTU tutorials as quickly as possible). Therefore, I don't think it's sufficient to fix the issue that we see in Marketplace, or for when search fields are used as a filter. We should still provide a scrim in these instances, as shown in attachment #761057 [details]. The swipe-to-dismiss gesture is more of a nice to have for those people that take the time and trouble to know about it. 

Secondly, I'm nervous that this gesture to dismiss the keyboard could conflict with 3rd party keyboards that use gestures to input words.

Comment 54

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10669

Pointer to Github pull-request

Comment 55

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 768259 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10669

Hi David,

Thanks for your feedback.
This patch is done mostly by your suggestion.

About the "entering a space when swipe down" issue, right now my approach would not make it input the key but the highlighting would still show, but I think this is OK.

Please help have a review on this patch.

Comment 56

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

I haven't tested this new behaviour, by just be aware the most Firefox OS phones right now have an haptic home button you can easily tap when sliding down near the bottom of the screen ;)

Comment 57

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Francis Djabri [:djabber] from comment #53)
> 
> I'm not totally against using a swipe to dismiss the keyboard, but I do have
> some concerns. 
> 
> Firstly, using swipe to dismiss is a hidden feature, even if we provide some
> information on FTU (evidence suggests that the majority of users skip past
> these FTU tutorials as quickly as possible). Therefore, I don't think it's
> sufficient to fix the issue that we see in Marketplace, or for when search
> fields are used as a filter. We should still provide a scrim in these
> instances, as shown in attachment #761057 [details]. The swipe-to-dismiss
> gesture is more of a nice to have for those people that take the time and
> trouble to know about it. 
>

I remember from my discussion with Neo, we would like to have a "first time tip" screen hover on the keyboard when the user triggers the keyboard for the first time.

I'll just start the "gesture" part implementation to get technical review first and won't be blocked the UI design of the "first time tip".

> Secondly, I'm nervous that this gesture to dismiss the keyboard could
> conflict with 3rd party keyboards that use gestures to input words.
We are going to implement this in our Gaia keyboard app., so 3rd-party could support/or override this behavior by its implementation.

If we need a whole-system gesture (for v1.2) to dismiss the keyboard, we would need to re-consider the use cases.

Thanks.

Comment 58

[David Flanagan [:djf]]

Comment on attachment 768259 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10669

The code looks good to me, except that I would prefer that in addition to a velocity threshold you also had a distance threshold. A single key press that happened to be very fast could be interpreted as a swipe.  I think you should make sure that dy > 100 or > 50% of the keyboard height or something.

I've got so many reviews in my queue this morning that I have not actually tried the code. My r+ is based on the assumption that you have tried it and that it works.

Comment 59

[Francis Djabri [:djabber]]

(In reply to Rudy Lu [:rudyl] from comment #57)
> (In reply to Francis Djabri [:djabber] from comment #53)
> > 
> > I'm not totally against using a swipe to dismiss the keyboard, but I do have
> > some concerns. 
> > 
> > Firstly, using swipe to dismiss is a hidden feature, even if we provide some
> > information on FTU (evidence suggests that the majority of users skip past
> > these FTU tutorials as quickly as possible). Therefore, I don't think it's
> > sufficient to fix the issue that we see in Marketplace, or for when search
> > fields are used as a filter. We should still provide a scrim in these
> > instances, as shown in attachment #761057 [details]. The swipe-to-dismiss
> > gesture is more of a nice to have for those people that take the time and
> > trouble to know about it. 
> >
> 
> I remember from my discussion with Neo, we would like to have a "first time
> tip" screen hover on the keyboard when the user triggers the keyboard for
> the first time.
> 
> I'll just start the "gesture" part implementation to get technical review
> first and won't be blocked the UI design of the "first time tip".

My main point is that I don't think that many users will read this tip. Even if they do, there's no guarantee that they will understand it, or whether they will remember it. So even if we have the tip, the swipe to dismiss gesture will remain a hidden feature and so we should not rely on it. So I suggest that we still implement the scrim as a fallback in the case of Marketplace and other instances where the view is completely filled with tap targets.

Comment 60

[Alex Keybl [:akeybl]]

Adding [NO_UPLIFT] so that we can review the landing on master prior to uplift.

QA - please remove [NO_UPLIFT] once this is verified working without major regression through exploratory testing.

Comment 61

[Neo Hsieh [:neo]]

Attachment: For FTU - with OK button

Comment 62

[Neo Hsieh [:neo]]

Attachment: For FTU - without OK button

Comment 63

[Neo Hsieh [:neo]]

Hi Francis, I think we can try to implement that and you can try it later. We will try to let some user use it and also all feedbacks are welcome.  If that way is not good enough, We can try to improve it or change it. How do you think ?

Comment 64

[Neo Hsieh [:neo]]

Attachment: For FTU - without bottom line

Comment 65

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: FTU tutorial image 1

Hi Neo,

Could you provide the image without the background as the attachment.
This is for us to do the responsive design.
Thanks.

Comment 66

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Neo,

Please refer to Comment 65.
Thanks.

Comment 67

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Flagging this with late-l10n since we are going to add a dialog which contains a [OK] button.
(Originally, keyboard app. did not have any localization resources).

Comment 68

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: FTU tutorial page 1 @2x

Hi Neo,

Please refer to the attachment, for the FTU tutorial image@2x.
As you can see, it is 550x580, instead of 578x626, 2x of the 289x313.
I will ping the author on if there is any reason for this.

Comment 69

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Neo,

After checking this with Rex, I think we could get
578x626 for 2x version.

Still not sure why 550x580 was given for FTU at that time.
Thanks.

Comment 70

[Neo Hsieh [:neo]]

Attachment: For FTU - 1X without background

Comment 71

[Neo Hsieh [:neo]]

Attachment: For FTU - 2X without background

Comment 72

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Remove qawanted for now to prevent it from appearing on QA's radar, will reset it to ask for QA to verify this change on Gaia master.

Comment 73

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 768259 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10669

Hi Jan,

I'd like to ask for your help to review this change,
https://github.com/RudyLu/gaia/commit/ae376b2583433f97205f27a62499fea904b36df2

This is part 2 of this patch to:
    1. Add the dialog for FTU tip of swipe down
    2. Refine the swipe down behavior not to show the highlighted key

The part 1 has been reviewed by David, hope that you can help on this since he is PTO.

Comment 74

[Jan Jongboom [:janjongboom] (inactive)]

Flashed this to my GP Keon (running Gecko from June 24):

1. For first time user it will show the screen when connecting to WiFi network (most likely) as this is the first time they need to type, so we're having like a FTU flow within a FTU flow, is this OK?
2. Based on the image I was expecting that I should swipe from just above the keyboard downwards but that doesn't work
3. Keys are still highlighted during the gesture

Comment 75

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Jan Jongboom [:janjongboom] from comment #74)
> Flashed this to my GP Keon (running Gecko from June 24):
> 
> 1. For first time user it will show the screen when connecting to WiFi
> network (most likely) as this is the first time they need to type, so we're
> having like a FTU flow within a FTU flow, is this OK?

Personally, I think this is OK.
Will double confirm this with Neo, our UX on keyboard.

> 2. Based on the image I was expecting that I should swipe from just above
> the keyboard downwards but that doesn't work

Oh really? :)
That's another part that needs UX comment.

> 3. Keys are still highlighted during the gesture

Yes, during the gesture, we still have highlighting.
This is because only when the touchend event is triggered, we would know "swipe down" occurs.

The highlighting effect will be deactivated immediately after "swipe down" is triggered.

--
Hi Neo,

Could you please help check Jan's comments on point 1 & 2?
Thanks.

Comment 76

[Neo Hsieh [:neo]]

Hi Jan, 

1. Due to sometimes users like to skip FTU and maybe press "Next Next Next... " Or they don't want to enter anything at first time use. So I think this hint image should be shown at first time keyboard launch. Not include in the standard FTU process. 

2. Yes, We consider this method before.  But finally we don't do that is about consistency. I know that is very interesting way to dismiss that hint image. 
Due to our FTU images all use the button to dismiss it(Next/Skip...), I think If I want to change that, That should change all FTU behavior. So, In this time, We don't change that.

Comment 77

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Jan,

Do you think we could get this through technical review first and land it in Gaia master to get some feedback?

Thank you.

Comment 78

[Jan Jongboom [:janjongboom] (inactive)]

See my comments on GH.

Comment 79

[Jan Jongboom [:janjongboom] (inactive)]

Comment on attachment 768259 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10669

r+ if stopPropgation + CSS is not possible.

Comment 80

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Merged to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/103f3635c241e208f84b6e8d80afb23731043c09

Comment 81

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

reset the qawanted since the code has been in Gaia *master*.
Please refer to Comment 60 for the original request.

Comment 82

[William Hsu [:whsu]]

I will verify this case since PVT build is not yet merged the patch.
Thanks!

Comment 83

[William Hsu [:whsu]]

Hi, all,

Could I have your help?
I found a serious problem while I verified this patch.
If you presses a key of visual keyboard and swipe the keyboard at the same time, the keyboard will crash.
Rudy used the build of master + b2g18. It still can reproduce.
So, it might not be gecko's problem.

Submitted a bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=892377

Comment 84

[Jan Jongboom [:janjongboom] (inactive)]

Due to the issues found in bug 892377, I backed out the merge in https://github.com/mozilla-b2g/gaia/commit/84c53c094e3c3698e486d1c3751afb250c630935

Comment 85

[Jan Jongboom [:janjongboom] (inactive)]

William Hsu [:whsu] 2013-07-11 00:40:42 PDT
* Description:
  This case happened on 
   1) Gaia-Master + MC
   2) Gaia-Master + B2g18
  and reproduced on unagi device.
  In early pvt build (2013-07-07-03-13-20), the bug cannot be reproduced.
  
  If user presses a key of keyboard and swipes the keyboard at the same time, the keyboard will crash.
  User presses any key of keyboard without getting any response.
  Attaching the video.
  -> http://goo.gl/8z871

* Reproduction steps:
  1. Launch the message app
  2. Tap pencil icon to edit a new text message. 
  3. Tap the text field
  4. Pressing a key and swipe the visual keyboard.
  5. Tap the text field
  6. Input a character
  7. Repeat step 4~6.

* Expected result:
  1. The keyboard is hidden
  2. User still can input character via keyboard.

* Actual result:
  Keyboard crashes and user cannot input any character.

* Reproduction build:(Gaia-Master/Mozilla-central-unagi-eng/2013-07-10-03-02-03)
  + Mercurial-Information
    - Gecko revision="04d8c309fe72"
    - Gaia revision=""
  + Git-information
    - Gecko revision="33510110c092162e4d6218e98d378fc9c39ebf63"
    - Gaia revision="b3ef9da9c967e8f33b7b750d986d395e1aa38c95"

Thanks!

Comment 87

[Florin Strugariu [:Bebe]]

guys will we have a pref or setting to disable this screen?
It's affecting the Gaia-UI Automated tests peaty hard

Comment 88

[Jason Smith [:jsmith]]

Sounds like William's testing above addresses the immediate QA Wanted request. When a new patch is ready for testing that is landed on master, feel free to mark qawanted again.

Comment 89

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

I think I have figured what happened in Comment 83, it is because isShowingAlternativesMenu will be set in a timer after we swipe to dismiss the keyboard.

And that flag wasn't reset, and cause us ignore all touchevent after we get the keyboard to show again.
--
(For Comment 88)
Hi Florin,

Yes, I am going to change the implementation to look at a entry in mozSettings.
So that we could disable the ftu tip dialog with that entry.

Will send an update patch later today.

Comment 90

[Alex Keybl [:akeybl]]

At this point, we're not comfortable with taking this change for 1.1 given the fact that it's

A) an enhancement request
B) very regression prone
C) too late in the release to take this kind of change

If you disagree with this blocking decision, please email b2g-release-drivers. Do not change this back to leo+ without conversation over email.

Comment 91

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Patch V2

Hi Jan,

Could you please help review this updated patch?
    1. To fix the issue that keyboard may ignore all touch event after swipe
    down.
    2. Also change from asyncStorage to mozSettings to keep ftu.enabled, so
    that we could disable it when doing automated testing of keyboard.

Thanks.

Comment 92

[Jan Jongboom [:janjongboom] (inactive)]

1. Shouldn't I be able to set `user_pref("keyboard.ftu.enabled", false);` to disable keyboard FTU? That doesn't work.
2. Found a bug (this is from New message screen in SMS), type `Jan`, swipe the keyboard down, tap the text field, type [SPACE]. The cursor disappears. Doesn't happen w/o the keyboard swipe.

Comment 93

[Jan Jongboom [:janjongboom] (inactive)]

(this is on the GP nightly build of 2013-07-08)

Comment 94

[Wayne Chang [:wchang]]

Clearing my NI - no longer a blocker

Comment 95

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Jan Jongboom [:janjongboom] from comment #92)
> 1. Shouldn't I be able to set `user_pref("keyboard.ftu.enabled", false);` to
> disable keyboard FTU? That doesn't work.

Should be mozSettings.
You may modify build/settings.py to see this entry.

> 2. Found a bug (this is from New message screen in SMS), type `Jan`, swipe
> the keyboard down, tap the text field, type [SPACE]. The cursor disappears.
> Doesn't happen w/o the keyboard swipe.

Cannot reproduce exactly the same issue as yours, but did see some strangeness when testing this, like the keyboard cannot open up again.
Will test this again with Bug 874754's patch.

Comment 96

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Just retest this patch with the latest pvt build.
https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi-eng/2013/07/2013-07-17-23-02-19/

It seems that this patch works fine.

--
I do encounter the case that sometimes the cursor will disappear on "To:" input field, but that is irrelevant to my patch since I did not trigger swipe.


Hi William,

Could you please help test this patch with the latest pvt build to help us evaluate this patch again?
Thank a lot for your help.

Comment 97

[Jan Jongboom [:janjongboom] (inactive)]

Comment on attachment 775117 [details]
Patch V2

No other issues found

Comment 98

[William Hsu [:whsu]]

Hi, Rudy and all,

Sorry for my late reply.
I cannot reproduce the bug of comment 85 mentioned after applying the Rudy's patch.

The Gecko is based on following build.
- https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi-eng/2013/07/2013-07-17-23-02-19/

The Gaia is Rudy's patch.
- https://github.com/RudyLu/gaia.git
- Branch: swipe_hide_keyboard_3

Thanks!

Comment 99

[Jason Smith [:jsmith]]

Pulling qawanted per comment 98.

Comment 100

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Landed to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/d306ee27bc553249a0fb49f77553309e93dd642b

Jan, William,

Thanks for the review and the evaluation of this patch.

Comment 101

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi :Bebe,

I checked the issue that you mentioned modifying the mozSettings cannot effectively disable the FTU screen of keyboard.

I think the cause would be that keyboard app only read the settings once during the app start up (right after the phone boots up).
So, if your marionette code would change the settings later than that, keyboard app would not know.

I will patch this up if you can help clarify this is the case you are facing.
Thank you and sorry for any inconvenience.

Comment 102

[Florin Strugariu [:Bebe]]

Hi :Rudy


I logged https://bugzilla.mozilla.org/show_bug.cgi?id=900905 for this specific issue.

We do a clean up of the environment before each test and then set the setting.

After the clean up we wait for the homescreen and FTU app to be visible and then set the necessary settings for the tests to run. I'm sure that after the keyboard app reads the settings and keyboard app will not know about the change.

We need this settings to be able to dismiss the FTU prompt before we run our tests

Thanks,
Bebe

Comment 103

[classicalbookworm]

As a user I like the swipe to dismiss idea. In fact that is what I tried to do the first time the keyboard got stuck in YouTube. If it functioned like the Notifications swipe bar that would great. It's already familiar and intuitive and it won't take up keyboard room. It has to be touch and swipe though, to avoid accidental closures, which would be frustrating. Just my two cents.

Comment 104

[William Hsu [:whsu]]

Thanks for all your help.
Verified it.

* Test Build:
 - Gaia:     c26480b22ce28c812c347290dd4bad090d83db6f
 - Gecko:    http://hg.mozilla.org/mozilla-central/rev/597287004ff5
 - BuildID   20131120062258
 - Version   28.0a1