Open Bug 1769175 Opened 3 years ago Updated 7 months ago

Firefox doesn't allow typing any characters with the SHIFT key in ESXi VM console.

Categories

(Web Compatibility :: Site Reports, defect, P3)

Firefox 100
x86
Windows 10

Tracking

(Webcompat Priority:P3, Webcompat Score:1)

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)

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.

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.

Component: Untriaged → Console
Product: Firefox → DevTools

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.

Component: Console → Untriaged
Product: DevTools → Firefox
Component: Untriaged → DOM: Editor
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86

Do you know what's up here?

Severity: -- → S3
Flags: needinfo?(masayuki)
Priority: -- → P3

Hmm, if the symptom occurs without any other 3rd party's tools, it means that Win32 API does not work properly.

and we use WM_CHAR messages in the message queue normally.

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.

Component: DOM: Editor → DOM: UI Events & Focus Handling
Flags: needinfo?(masayuki) → needinfo?(fireballiso)

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --

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).

Flags: needinfo?(fireballiso)
Attachment #9278049 - Attachment mime type: application/octet-stream → text/plain

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:

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?

Flags: needinfo?(fireballiso)

Yes, this problem happens when I am in Troubleshoot Mode - no SHIFTed characters when typing in the VM console in a browser tab.

Flags: needinfo?(fireballiso)

Thank you, but I have no more idea to investigate this. Ccing some Win32 experts...

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.

Flags: needinfo?(fireballiso)

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.

Flags: needinfo?(fireballiso)

Okey, thanks. Then, this must be a bug of the ESXimweb client service. We should contact VMware.

Component: DOM: UI Events & Focus Handling → Desktop
Product: Core → Web Compatibility

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

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dschubert)
Severity: S3 → S4
User Story: (updated)
Flags: needinfo?(dschubert)
Priority: -- → P3
Webcompat Priority: --- → P3
Webcompat Score: --- → 1
User Story: (updated)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: