Closed
Bug 500275
Opened 15 years ago
Closed 15 years ago
when clicking on the URL bar in Fennec on my HTC, the virtual keyboard is not displayed
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 1.0b2+ | --- |
People
(Reporter: jmaher, Assigned: mfinkle)
References
Details
Attachments
(1 file)
1.55 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
on my HTC Touch Pro with the latest build from the build team, I click on the URL bar and the awesome bar is displayed, but the virtual keyboard is never displayed. I ran into this problem on the n810 last week as well, but it was not 100% reproducible. Verified in both portrait and landscape mode
Flags: wanted-fennec1.0?
Comment 1•15 years ago
|
||
joel says that this only happens in chrome. content continues to bring up the software keyboard. joel, can you get a regression range?
Comment 2•15 years ago
|
||
I have a build from changeset 416c5b900b75 and one from changeset cabb8925dcd3 (plus the patch from 497934). The former pops up the keyboard correctly, and the latter doesn't. So this is a regression from bug 178324.
Comment 3•15 years ago
|
||
This is what I see when I click in the URL bar, then click to dismiss the autocomplete popup: ResetInputState SetIMEEnabled: Disabled GetIMEEnabled: Disabled ResetInputState WM_SETFOCUS ResetInputState SetIMEEnabled: Disabled ResetInputState GetIMEEnabled: Disabled ResetInputState WM_SETFOCUS ResetInputState SetIMEEnabled: Disabled
Comment 4•15 years ago
|
||
neil, could use your help here.
Updated•15 years ago
|
Component: Windows Mobile → XUL
OS: Windows Mobile 6 Professional → All
Product: Fennec → Core
QA Contact: mobile-windows → xptoolkit.widgets
Hardware: ARM → All
Comment 5•15 years ago
|
||
Firefox trunk on WinXP, this issue seems not to be occured in its URLbar but Fennec both on WinXP and on Linux have the same issue only in its URLbar. Text entry in web page (ex. google.com) has no issue.
Comment 6•15 years ago
|
||
DEBUG_FOCUS log: Clicking Fennec URLbar. <<SetFocus>> Shift Focus: input Flags: 4098 Current Window: 0xb79a8900 New Window: 0xb79a8900 Current Element: (nil) In Active Window: 1 In Focused Window: 1 **Element (none) has been blurred Update Caret: 0 1 **Element input has been focused from window [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 4098] Update Caret: 0 0 <<SetFocus>> <<SetFocus>> Clicking text input field in google.com <<SetFocus>> Shift Focus: input Flags: 4098 Current Window: 0xb79a8900 New Window: 0xb79b9680 Current Element: (nil) In Active Window: 1 In Focused Window: 0 **Element (none) has been blurred **Element input has been focused from html [Newdoc: 1 FocusChanged: 1 Raised: 0 Flags: 4098] Update Caret: 0 1 The second argument of UpdateCaret is different.
Comment 7•15 years ago
|
||
OK. Fennec URLbar is captured by this check. http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager.cpp#1667
Comment 8•15 years ago
|
||
I was wrong. The check is not problem.
Comment 9•15 years ago
|
||
> <<SetFocus>>
> Shift Focus: input Flags: 4098 Current Window: 0xb79a8900 New Window:
> 0xb79a8900 Current Element: (nil) In Active Window: 1 In Focused Window: 1
> **Element (none) has been blurred
> Update Caret: 0 1
> **Element input has been focused from window [Newdoc: 0 FocusChanged: 1 Raised:
> 0 Flags: 4098]
> Update Caret: 0 0
> <<SetFocus>>
> <<SetFocus>>
So, these "SetFocus" is problem?
Comment 10•15 years ago
|
||
When I use keyboard shortcut (Ctrl+L), the issue is not happened. At that time, SetFocus is called only once after UpdateCaret().
Comment 11•15 years ago
|
||
log with flags of SetFocus. by keyboard shortcut (good): <<SetFocus: 0>> Shift Focus: 0xbf83053c Flags: 0 Current Window: 0xb78a8900 New Window: 0xb78a8900 Current Element: (nil) In Active Window: 1 In Focused Window: 1 **Element (none) has been blurred Update Caret: 0 1 **Element input has been focused from window [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 0] Update Caret: 1 0 <<SetFocus: 2> by mouse clicking (bad): <<SetFocus: 4098>> Shift Focus: 0xbfe3fb48 Flags: 4098 Current Window: 0xb78a8900 New Window: 0xb78a8900 Current Element: (nil) In Active Window: 1 In Focused Window: 1 **Element (none) has been blurred Update Caret: 0 1 **Element input has been focused from window [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 4098] Update Caret: 0 0 <<SetFocus: 0>> This is bad? <<SetFocus: 2>>
Comment 12•15 years ago
|
||
The caret updating only affects whether the text caret appears. In comment 6, it's correct for the value to be different as you're focusing a different document. There isn't any debugging info in the focus manager that would help debug this. You want to be debugging the calls to IMEStateManager. (the line in comment 11 that says 'This is bad?' suggests someone is calling element.focus() on an element that isn't focusable.
Comment 13•15 years ago
|
||
Neil: this is blocking beta 2 for maemo and alpha 2 for windows mobile -- need fix as soon as possible so we can push out later this week
tracking-fennec: --- → 1.0b2+
Comment 14•15 years ago
|
||
Seems to only be a problem the first time I use the urlbar. After that it works fine. However, when it fails, debugging shows that the urlbar textbox is readonly at the time when it is focused, and thus when IME is checked, so IME is never enabled for the textbox. It seems like this would either be fixed by bug 488420 or to update the readonly state on the textbox before it gets focused.
Comment 15•15 years ago
|
||
Neil, the way the fennec url bar works is that it is first in readonly mode, we change the mode to edit, then focus it: http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser-ui.js#175
Comment 16•15 years ago
|
||
(In reply to comment #15) > Neil, the way the fennec url bar works is that it is first in readonly mode, we > change the mode to edit, then focus it: > > http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser-ui.js#175 This code is being called after the url field is already focused (the mouse clicking on it has already focused it). It works if I add code to blur the textbox just before focusing it again. this._edit.inputField.blur(); this._edit.inputField.focus();
Comment 17•15 years ago
|
||
it also works if I remove the readonly style on the textbox.
Comment 18•15 years ago
|
||
Alternatively, you could cancel the mousedown event if you don't want the default focusing on mouse behaviour, then just use the code you linked to to do the focusing. Haven't tested that though.
Assignee | ||
Comment 19•15 years ago
|
||
Uses the extra blur approach. Also removes an unused "blur" listener. Tested on n810.
Assignee: nobody → mark.finkle
Attachment #385129 -
Flags: review?(gavin.sharp)
Updated•15 years ago
|
Attachment #385129 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 20•15 years ago
|
||
https://hg.mozilla.org/mobile-browser/rev/f322879c015b
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 22•15 years ago
|
||
Using the build with this fix, on my 810, I'm not getting the virtual keyboard when my hard keyboard is already closed and I click on the URL bar.
Assignee | ||
Comment 23•15 years ago
|
||
Al - try it with the newest nightlies. We landed some additional changes from other bugs.
Comment 24•15 years ago
|
||
Nope. Trying with today's build with the timestamp "26-Jun-2009 01:28" and I still get not virtual kb when the hard kb is closed.
Reporter | ||
Updated•13 years ago
|
Flags: wanted-fennec1.0?
You need to log in
before you can comment on or make changes to this bug.
Description
•