Closed
Bug 750511
Opened 12 years ago
Closed 12 years ago
Samsung Galaxy Note's stylus will dismiss keyboard in Awesome-Screen when pen is near screen
Categories
(Firefox for Android Graveyard :: Keyboards and IME, defect)
Tracking
(firefox14 verified, firefox15 verified, blocking-fennec1.0 +)
VERIFIED
FIXED
Firefox 15
People
(Reporter: aaronmt, Assigned: wesj)
Details
Attachments
(1 file)
5.26 KB,
patch
|
mfinkle
:
review+
joe
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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)
Comment 1•12 years ago
|
||
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•12 years ago
|
||
Tried out a couple of forms, and sign-ins -- looks like this only affects our Awesome Bar
Reporter | ||
Comment 3•12 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•12 years ago
|
blocking-fennec1.0: --- → ?
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•12 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.
akebyl - will you be adding this in the Release Notes known issue?
Reporter | ||
Updated•12 years ago
|
status-firefox14:
--- → affected
status-firefox15:
--- → affected
Comment 7•12 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.
Comment 8•12 years ago
|
||
Wes - Let's get you a Note. This might be in the gesture handling code (just a guess)
Assignee: nobody → wjohnston
blocking-fennec1.0: ? → +
Comment 9•12 years ago
|
||
Sending a Note via the MV <-> SF delivery service IT device #08109. Should be up there on Wednesday.
Reporter | ||
Comment 10•12 years ago
|
||
Wes is now a happy Note user.
Assignee | ||
Comment 11•12 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?
Comment 12•12 years ago
|
||
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•12 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•12 years ago
|
||
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 15•12 years ago
|
||
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 16•12 years ago
|
||
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•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/54d0d95a2b5f
Assignee | ||
Comment 18•12 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?
Comment 19•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/54d0d95a2b5f
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Comment 20•12 years ago
|
||
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•12 years ago
|
||
Verified Fixed Nightly (05/27), Galaxy Note (2.3.4)
Reporter | ||
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 22•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/192b18bb4d24
Updated•12 years ago
|
Comment 23•12 years ago
|
||
Verified in Aurora 2012-05-30
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•