Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Samsung Galaxy Note's stylus will dismiss keyboard in Awesome-Screen when pen is near screen

VERIFIED FIXED in Firefox 14

Status

()

Firefox for Android
Keyboards and IME
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: aaronmt, Assigned: wesj)

Tracking

Trunk
Firefox 15
ARM
Android
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox14 verified, firefox15 verified, blocking-fennec1.0 +)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Currently when the Galaxy Note's pen's tip is close enough to the screen, the virtual keyboard will dismiss thus making it inconvenient to use the stylus as a navigation tool in order to browse the web.

The stylus works fine on the stock browser.

Irina, how popular is the Galaxy Note?


--
Nightly (04/30)
Samsung Galaxy Note (Android 2.3)
aaronmt, does the stylus dismiss the VKB when entering text into a page's text form? Or does this bug only affect the Awesome Bar?
(Reporter)

Comment 2

5 years ago
Tried out a couple of forms, and sign-ins -- looks like this only affects our Awesome Bar
(Reporter)

Comment 3

5 years ago
Note users who download Firefox Beta tomorrow might run into this. Should this be a release note somewhere visible on the Google Play store or in the list of known issues?
(Reporter)

Updated

5 years ago
blocking-fennec1.0: --- → ?

Comment 4

5 years ago
I'll be updating the What's New Tab tmrw to include multi locale support. The Galaxy Note is the top 3rd most popular device (7k users), so I'll add a note for this known issue as well

Comment 5

5 years ago
(In reply to Aaron Train [:aaronmt] from comment #0)
> Currently when the Galaxy Note's pen's tip is close enough to the screen,
> the virtual keyboard will dismiss thus making it inconvenient to use the
> stylus as a navigation tool in order to browse the web.
> 
> The stylus works fine on the stock browser.
> 
> Irina, how popular is the Galaxy Note?
> 


It is rather popular. As Jaclyn says, not only is the Galaxy Note one of the top devices for current users, but it is a model that is selling pretty well, so it should be a P1.

Comment 6

5 years ago
akebyl - will you be adding this in the Release Notes known issue?
(Reporter)

Updated

5 years ago
status-firefox14: --- → affected
status-firefox15: --- → affected

Comment 7

5 years ago
(In reply to Jaclyn Fu from comment #6)
> akebyl - will you be adding this in the Release Notes known issue?

I've release noted it.
Wes - Let's get you a Note. This might be in the gesture handling code (just a guess)
Assignee: nobody → wjohnston
blocking-fennec1.0: ? → +
Sending a Note via the MV <-> SF delivery service IT device #08109. Should be up there on Wednesday.
(Reporter)

Comment 10

5 years ago
Wes is now a happy Note user.
(Assignee)

Comment 11

5 years ago
So we hide the keyboard on MotionEvents here:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/AwesomeBarTabs.java#741

Since the note isn't running ICS, we can't use Android's built in stuff for MotionEvent.getToolType(). The SPen SDK also doesn't seem to give much helpful stuff beyond a canvas class you can draw on:

http://innovator.samsungmobile.com/cms/cnts/knowledge.detail.view.do?platformId=1&cntsId=10210

So, I think I'm going to look at the size of the touch on screen and if there's only one and its small enough, we'll leave the keyboard on screen? Sound good? Better ideas?
wesj, what kind of MotionEvent do we actually receive when the stylus has not even touched the screen yet? Do MotionEvent.getDeviceId() or getPressure() return any interesting differences between the Note's stylus and your finger?
(Assignee)

Comment 13

5 years ago
Dang it. I was wrong. When the pen is near the screen, but not on it, we actually hit this FocusChange listener:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/AwesomeBar.java#205
(Assignee)

Comment 14

5 years ago
Created attachment 627031 [details] [diff] [review]
Patch

So this switches us to use one single massive onInterceptTouchEvent handler for the AwesomeBarTabs view (aka everything but the search box). If you tap anywhere on that with anything, we hide the keyboard (We have to use onInterceptTouchEvent instead of onTouchEvent because (I think) listviews and tabhost already have touch handlers listening motion events which prevent onTouchEvent from firing on the AwesomeBarTabs view).

Removing the focus change listener fixes the stylus-near-the-page problem (but it will still go away if the stylus touches the screen). What do you think?
Attachment #627031 - Flags: review?(mark.finkle)
Comment on attachment 627031 [details] [diff] [review]
Patch

Review of attachment 627031 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/AwesomeBarTabs.java
@@ +1005,5 @@
> +
> +    @Override
> +    public boolean onInterceptTouchEvent(MotionEvent ev) {
> +        InputMethodManager imm = (InputMethodManager)(getContext().getSystemService(Context.INPUT_METHOD_SERVICE));
> +        imm.hideSoftInputFromWindow(getWindowToken(), 0);

You can just call AwesomeBarTabs.hideSoftInput(), a helper function that already consolidates this hideSoftInputFromWindow() boilerplate.
Comment on attachment 627031 [details] [diff] [review]
Patch

Sounds like this will address the primary issue - non-touches causing the keyboard to close. As long as we don't regress current touch-behavior, I am OK with this change.

Don't forget Chris' suggestion.
Attachment #627031 - Flags: review?(mark.finkle) → review+
(Assignee)

Comment 17

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/54d0d95a2b5f
(Assignee)

Comment 18

5 years ago
Comment on attachment 627031 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): The release of the Galaxy Note
User impact if declined: Note users may be (more?) frustrated
Testing completed (on m-c, etc.): Landed on MC 5/25
Risk to taking this patch (and alternatives if risky): Low risk. Should have the same behavior as the old code, without the bug.
String or UUID changes made by this patch:
Attachment #627031 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/54d0d95a2b5f
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Comment on attachment 627031 [details] [diff] [review]
Patch

Please land ASAP for the Fennec beta build.
Attachment #627031 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Reporter)

Comment 21

5 years ago
Verified Fixed

Nightly (05/27), Galaxy Note (2.3.4)
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Comment 22

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/192b18bb4d24
status-firefox14: affected → fixed
status-firefox15: affected → fixed
Verified in Aurora 2012-05-30
status-firefox14: fixed → verified
status-firefox15: fixed → verified
You need to log in before you can comment on or make changes to this bug.