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

phone id: 14321

There is a workaround, just hit the content

This is pretty bad as a work around. Seriously.

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

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

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

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.

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

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.

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.

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.

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

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

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.

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

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.

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.

(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.

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

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

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.

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

(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

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.

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.

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.

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

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!

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.

(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.

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.

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?

(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.

(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.

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.

(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.

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.

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

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.

Thank you, Chris!

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

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.

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 ?

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.

Pointer to Github pull-request

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.

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

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 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.

(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.

Pointer to Github pull-request

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.

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 ;)

(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 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.

(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.

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.

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 ?

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

Hi Neo, Please refer to Comment 65. Thanks.

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).

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.

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.

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 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.

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

(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.

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.

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.

See my comments on GH.

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.

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

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

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

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

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

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!

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

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.

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.

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.

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.

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.

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

Clearing my NI - no longer a blocker

(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.

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 on attachment 775117 [details] Patch V2 No other issues found

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!

Pulling qawanted per comment 98.

Landed to Gaia master, https://github.com/mozilla-b2g/gaia/commit/d306ee27bc553249a0fb49f77553309e93dd642b Jan, William, Thanks for the review and the evaluation of this patch.

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.

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

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.

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