Firefox doesn't allow typing any characters with the SHIFT key in ESXi VM console.
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P3, Webcompat Score:1)
People
(Reporter: fireballiso, Unassigned)
References
()
Details
(Keywords: webcompat:site-wait)
User Story
platform:windows,mac,linux impact:workflow-broken configuration:general affects:few user-impact-score:8
Attachments
(1 file)
|
150.98 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
When using virtual machine (VM) consoles in VMWare ESXi 7.0.3 with Firefox (latest version is 100, and a few months of prior versions), try to type any characters that require the SHIFT key (uppercase, symbols, etc.)
Actual results:
The characters that are typed with the SHIFT key appear as if the SHIFT key wasn't pressed at all. This bug happens every time the characters are typed, and even prevents me from logging in to any VM through the virtual console if any SHIFTed characters are required.
Expected results:
Characters typed with the SHIFT key should appear as you would expect (i.e. UPPERCASE, symbols, etc.). The problem doesn't seem to be with the VMs or ESXi, since I can type any SHIFTed characters in the same VM consoles when using another browser like Chrome.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Reporter | ||
Comment 2•3 years ago
|
||
No, I don't think this should be moved to the 'DevTools::Console' component. Unfortunately, I don't seem to be allowed to correct that.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Do you know what's up here?
Comment 4•3 years ago
|
||
Hmm, if the symptom occurs without any other 3rd party's tools, it means that Win32 API does not work properly.
- https://searchfox.org/mozilla-central/rev/1c391443f770eddc7cde9e52dba5ef50cc233c06/widget/windows/KeyboardLayout.cpp#852,859,862,865,869,872,875,878
- https://searchfox.org/mozilla-central/rev/1c391443f770eddc7cde9e52dba5ef50cc233c06/widget/windows/nsWindowDbg.h#55
and we use WM_CHAR messages in the message queue normally.
- https://searchfox.org/mozilla-central/rev/1c391443f770eddc7cde9e52dba5ef50cc233c06/widget/windows/KeyboardLayout.cpp#1590,1593,1603
- https://searchfox.org/mozilla-central/rev/1c391443f770eddc7cde9e52dba5ef50cc233c06/widget/windows/KeyboardLayout.cpp#1663,1668-1669
- https://searchfox.org/mozilla-central/rev/1c391443f770eddc7cde9e52dba5ef50cc233c06/widget/windows/KeyboardLayout.cpp#2063
So, I think that it must be the environment is not in the usual situation...
fireballiso:
Could you attach a log file of just typing Shift + A with launching Firefox with setting the following environment variables:
MOZ_LOG to NativeKeyWidgets:5,KeyboardLayoutWidgets:5,sync (if you use Firefox 97 or later, KeyboardHandler:5,sync)
MOZ_LOG_FILE to the path to a file of the log file
Note that the log file records everything which you type and all keys in your active keyboard layout. Therefore, be careful. You should just launch firefox, and type Shift + A and close firefox with mouse, that's enough.
Comment 5•3 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
| Reporter | ||
Comment 6•3 years ago
|
||
Here's a log file with me typing Shift+A. Hopefully it's what you need; I don't have any problem with the Shift key except when I'm on the VMWare ESXi client website, in a virtual machine console (graphical desktop or terminal - both have the issue).
| Reporter | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Thank you!
V/KeyboardHandler VK_7 (8): NormalChar(Shift, "'&' (0x0026)") (ret=1)
V/KeyboardHandler VK_8 (9): NormalChar(Shift, "'*' (0x002A)") (ret=1)
V/KeyboardHandler VK_9 (10): NormalChar(Shift, "'(' (0x0028)") (ret=1)
V/KeyboardHandler VK_A (11): NormalChar(Shift, "'A' (0x0041)") (ret=1)
V/KeyboardHandler VK_B (12): NormalChar(Shift, "'B' (0x0042)") (ret=1)
V/KeyboardHandler VK_C (13): NormalChar(Shift, "'C' (0x0043)") (ret=1)
So, we succeeded to get the keyboard layout correctly. Shift state provides upper case characters, etc. And the log of WM_KEYDOWN message handling is here:
I/KeyboardHandler 3fa4ffde90 NativeKey::NativeKey(aWidget=0x1f17a0dbe00 { GetWindowHandle()=0x35065e }, aMessage={ message=WM_KEYDOWN, virtual keycode=VK_A, repeat count=1, scancode=0x1E, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x35065e, aModKeyState={ NumLock | Shift }), sLatestInstance=0x0
D/KeyboardHandler 3fa4ffde90 NativeKey::GetFollowingCharMessage(), succeeded to retrieve next char message, aCharMsg={ message=WM_CHAR, character code='A' (0x0041), repeat count=1, scancode=0x1E, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x35065e
I/KeyboardHandler 3fa4ffde90 NativeKey::InitWithKeyOrChar(), removed char message, { message=WM_CHAR, character code='A' (0x0041), repeat count=1, scancode=0x1E, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x35065e
D/KeyboardHandler 3fa4ffde90 NativeKey::GetFollowingCharMessage(), there are no char messages
I/KeyboardHandler 3fa4ffde90 NativeKey::NativeKey(), mKeyboardLayout=0x04090409, mFocusedWndBeforeDispatch=0x35065e, mDOMKeyCode=VK_A, mKeyNameIndex=USE_STRING, mCodeNameIndex=KeyA, mModKeyState={ NumLock | Shift }, mVirtualKeyCode=VK_A, mOriginalVirtualKeyCode=VK_A, mCommittedCharsAndModifiers={ 'A' (0x0041) [NumLock | Shift] }, mInputtingStringAndModifiers={}, mShiftedString={}, mUnshiftedString={}, mShiftedLatinChar=NULL (0x0000), mUnshiftedLatinChar=NULL (0x0000), mScanCode=0x001E, mIsExtended=false, mIsRepeat=false, mIsDeadKey=false, mIsPrintableKey=true, mIsSkippableInRemoteProcess=false, mCharMessageHasGone=false, mIsOverridingKeyboardLayout=false
D/KeyboardHandler 3fa4ffde90 NativeKey::HandleKeyDownMessage(), initializing keydown event...
I/KeyboardHandler 3fa4ffde90 NativeKey::InitKeyEvent(), initialized, aKeyEvent={ mMessage=eKeyDown, mKeyNameIndex=USE_STRING, mKeyValue="A", mCodeNameIndex=KeyA, mKeyCode=VK_A, mLocation=KEY_LOCATION_STANDARD, mModifiers=NumLock | Shift, DefaultPrevented()=false }
I/KeyboardHandler 3fa4ffde90 NativeKey::HandleKeyDownMessage(), dispatching keydown event...
I/KeyboardHandler 3fa4ffde90 NativeKey::HandleKeyDownMessage(), dispatched keydown event, dispatched=true, defaultPrevented=false
I/KeyboardHandler 3fa4ffde90 NativeKey::HandleKeyDownMessage(), tries to be dispatching keypress events with retrieved char messages...
D/KeyboardHandler 3fa4ffde90 NativeKey::DispatchKeyPressEventsWithRetrievedCharMessages(), initializing keypress event...
I/KeyboardHandler 3fa4ffde90 NativeKey::InitKeyEvent(), initialized, aKeyEvent={ mMessage=eKeyPress, mKeyNameIndex=USE_STRING, mKeyValue="A", mCodeNameIndex=KeyA, mKeyCode=Invalid DOM keyCode (0x00000000), mLocation=KEY_LOCATION_STANDARD, mModifiers=NumLock | Shift, DefaultPrevented()=false }
I/KeyboardHandler 3fa4ffde90 NativeKey::DispatchKeyPressEventsWithRetrievedCharMessages(), dispatching keypress event(s)...
I/KeyboardHandler 3fa4ffde90 NativeKey::DispatchKeyPressEventsWithRetrievedCharMessages(), dispatched keypress event(s), dispatched=true, consumed=false
D/KeyboardHandler 3fa4ffde90 NativeKey::~NativeKey(), destroyed
The WM_KEYDOWN message is followed by a WM_CHAR message for A as expected. And mCommittedCharsAndModifiers is initialized with A as expected. Finally, InitKeyEvent initializes an eKeyPress event with mKeyNameIndex=USE_STRING, mKeyValue="A", and it's dispatched correctly. So, Shift + A should cause inputting A rather than a according to this log.
Our editor handles the mKeyValue as-is:
- https://searchfox.org/mozilla-central/rev/c6620104602decf1af7c6a9f78692426db6a5da2/editor/libeditor/TextEditor.cpp#261,264,266-267
- https://searchfox.org/mozilla-central/rev/c6620104602decf1af7c6a9f78692426db6a5da2/widget/TextEventDispatcher.cpp#620,626,632-634
I have no idea what's going on...
fireballiso:
Do you reproduce this bug even if you use "safe mode" of Firefox or use a new (clean) profile of Firefox?
- https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode
- https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
I suspect that an addon touches the editor atkeypressevent is received in editor.
| Reporter | ||
Comment 9•3 years ago
|
||
Yes, this problem happens when I am in Troubleshoot Mode - no SHIFTed characters when typing in the VM console in a browser tab.
Comment 10•3 years ago
|
||
Thank you, but I have no more idea to investigate this. Ccing some Win32 experts...
Comment 11•3 years ago
•
|
||
Oh, I perhaps misunderstood the report. Do you mean that you type in a web app which is provided by VMware? I understood your report is that you typed something in VM on VMware ESXi. If the former is correct, this must be a bug of VMware's web app because your log is an evidence which Gecko dispatches correct event in your environment.
| Reporter | ||
Comment 12•3 years ago
|
||
The problem happens in the Firefox browser when I'm connected to the ESXi web client service. It doesn't happen when I'm using the Chrome browser with the same web service, so it didn't seem to be a VMWare problem.
It wasn't always a problem in Firefox. Sometime in the past 6-12 months, something changed to cause this issue.
Comment 13•3 years ago
|
||
Okey, thanks. Then, this must be a bug of the ESXimweb client service. We should contact VMware.
Updated•3 years ago
|
Comment 15•1 year ago
|
||
I can not test the issue since I do not have the proper set-up, but based on the comments made on the issue, I will class this as a NEW issue
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•7 months ago
|
Description
•