We've had several reports that the SHB is too easy to accidentally press while typing on the Keyboard. We decided offline that, if bug 1170863 doesn't fix this issue, we'll expand the SHB container, thus adding some dead space so that touches on the border of the System app don't send the user to the Homescreen.

Spoiler alert: bug 1170863 won't help.

Mike, based on comment 1, can you take this? Thanks. Amy, Eric, I'm not sure which one of you works on this, or if it's someone else. Could you help to provide a new design here? I'm thinking we should just increase the background region of the SHB, but keep the SHB itself, including its clickable area the same.

I'll either fix this, or find someone else to help out. Waiting on UX for now.

I believe Hung worked on this previously. Hung feel free to redirect if I'm mistaken. Thanks!

Hi There I've provided 2 options: 1. Increase the SHB row height to match the VKB row height. 2. Add 25% of deadspace to the top of the SHB bar. I prefer option 1 but like idea of having visual impact of option 2. Please refer to the attach spec for more information and let me know your thoughts. Cheers!

I did some testing on this on 2 people, and it seems like the second option is vastly superior for solving the problem. However, it looks weird visually. Mike, could we separate the tappable and visible regions of the SHB? The visible region would be vertically centered along the black background, but the tappable region would be pinned to the bottom of this region. This is definitely looking like the best option.

As an addendum to comment 6, we would be extending the dead space by 1rem above the SHB, as in option 2 from attachment 8616003 [details].

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #6) > I did some testing on this on 2 people, and it seems like the second option > is vastly superior for solving the problem. However, it looks weird visually. > > Mike, could we separate the tappable and visible regions of the SHB? The > visible region would be vertically centered along the black background, but > the tappable region would be pinned to the bottom of this region. This is > definitely looking like the best option. I'm not exactly sure what this means. Right now, only the circle is tapable, while the visible black region is not. It sounds like are are talking about increasing the height of the black region to ~5rem, but then moving the tapable circle down (ie. not vertically centered). Is that correct?

Yes, but we want the circle to visually appear as though it were vertically centered. The tappable region would be pinned to the bottom of the black region, but would have the same dimensions as the SHB currently does. I'll draw a diagram.

Here's a diagram explaining what I mean.

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #10) > Created attachment 8616277 [details] > Diagram of separation between visual SHB and clickable region > > Here's a diagram explaining what I mean. I see. This is certainly possible with a little rework of the SHB, but I disagree with the approach. Having some of the circle un-clickable to avoid false positives with the keyboard seems like it is causing more problems then it's fixing. But let's get some UX feedback on the approach. Rob or Hung, would you care to comment on attachment 8616277 [details]?

Sure, that's understandable. I'd like to mention that I tested this myself and on 2 people, and neither I nor them was thrown off by the slightly different positioning. It also seemed to have solved the original problem described in comment 0.

Thanks for additional exploration! I threw together a concept that combines the best of both worlds. Have a look and let me know if this works.

Reza is going to have a look.

Reza, will you be able to get this done and landed by Friday?

The solution seems straight forward. I'll get started right away. Shooting for Friday or sooner.

FYI: I'm using a Flame and have not tested on an Aries device yet.

Comment on attachment 8620519 [details] PR: added 1rem of dead space Thanks for the patch, Reza. This doesn't seem to implement the whole spec. 1. The total height of the SHB is still the same with this patch. It should increase to 5rem, with that 1rem of dead space. 2. attachment 8616691 [details] also called for the tappable width of the SHB to increase to 7rem.

I see, thanks for the correction. I'll have the PR updated shortly.

Comment on attachment 8620606 [details] PR: updated after feedback The patch is a-ok, let's land it and see how much it helps! :)

I just noticed a small issue with the fullscreen + landscape. It's fixed and the PR was updated.

Reza, is this ready to land? Generally, small fixes like you mentioned in comment 26 don't require re-review.

Yes. Let's land it.

I'm respinning the Gu5 task which seems to have failed for unknown reasons. If and when that succeeds, I'll land this. If it doesn't, we'll need you to take another look at it. Reza, needinfo only so that you see this: in the future, you can set the 'checkin-needed' keyword when a patch is ready to land. Don't bother with that this time, as I'm going to take this bug to completion due to the time-sensitive nature of it. Thanks again for your work on this.

My 3 respins for this went without issue, so I landed it. https://github.com/mozilla-b2g/gaia/commit/d5de92b9dc1cf9cfe37cc79de4c69598b61d9b5d

This issue is verified fixed on the latest Nightly Dogfood Spark Aries build. Actual Results: The SHB is not easily pressed when pressing the space bar. Environmental Variables: Device: Aries 3.0 BuildID: 20150626120208 Gaia: 8a1e4ae522c121c5cacd39b20a5386ec9055db82 Gecko: 56e207dbb3bd Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 41.0a1 (3.0) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0