Open Bug 1645571 Opened 4 years ago Updated 12 hours ago

Onscreen keyboard dismissing itself, Win10 tablet mode, taskbar auto-hide

Categories

(Core :: Widget: Win32, defect, P2)

Product:
Core
Component:
Widget: Win32
Platform:
x86_64
Windows 10
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox81 --- affected
firefox84 --- affected
firefox89 --- affected
firefox90 --- affected
firefox91 --- affected
firefox104 --- ?

People

(Reporter: alex, Assigned: cmartin)

References

Details

(Whiteboard: [win:touch])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Windows 10 running in tablet mode, with the taskbar 'auto-hide' setting enabled.
'Tap' any text entry field including but not limited to the address bar.

The same is the case for Firefox Nightly 79.0a1 (2020-06-12) (64-bit).

I am running a Lenovo L390 Yoga (2-in-1 laptop with wacom layer, and touchscreen) with up-to date Windows 10 build 2004, all Lenovo software/firmware up to date.

Actual results:

The onscreen keyboard appears, and then automatically dismisses itself as soon as the animation to appear is finished. You cannot make the keyboard reappear until you 'tap' out of the text field, and then back in it again, when the onscreen keyboard once again exhibits the same behavior continuously and consistently.

Expected results:

The onscreen keyboard appears, and persists, until it is manually dismissed, the way it behaves in the new chromium based Microsoft Edge under the same circumstances.

OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Win32
Product: Firefox → Core

I have exactly the same problem on two different 2in1 Windows 10 devices. When operating in tablet mode with the task bar auto hide feature turned on the onscreen keyboards appears momentarily and then goes away as the task bar hides itself.

The on screen keyboard works properly in Chrome and the new Edge browsers with the task bar auto hide feature turned on.

Devices

  • Microsoft Surface Go
  • Dell XPS13 7390 2in1

Windows 10

  • Version 2004

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Severity: -- → S3
Flags: needinfo?(jmathies)
Priority: -- → P2

This only started happening after update to Windows 10 2004. Looks like tablet mode had some changes introduced: https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-whats-new#new-tablet-experience-for-2-in-1-convertible-pcs-build-18970

I have a Surface Pro 6 with OS build 18363.959 that works fine in tablet mode. Also a Surface Go 2 that used to work fine, but after update to 2004 (OS build 19041.388) now exhibits the described behavior in Firefox - as soon as the on-screen keyboard finishes sliding up into position, Firefox resizes, and the OSK disappears. As the OSK slides back down, Firefox appears to only fill half the screen and I can briefly see the desktop in the background. As soon as the OSK finishes the slide animation, Firefox resizes back to fill the screen.

ui.osk.debug.keyboardDisplayReason is the same for windows 1909 and 2004 - IITM: GetInTabletMode=true.

Firefox Develop Edition 79.0b9
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

(In reply to Antony O from comment #4)

This only started happening after update to Windows 10 2004. Looks like tablet mode had some changes introduced: https://docs.microsoft.com/en-us/windows-insider/at-work-pro/wip-4-biz-whats-new#new-tablet-experience-for-2-in-1-convertible-pcs-build-18970

Hello, I realized this before update 2004. Found several reports of this with earlier versions of firefox. For me, the problem appeared with the new firefox version which was completly redisigned as it says.
Hardware: Surface Pro 5 and Acer mini tablet

Hope it will be solved soon.

¡Hola!

Found this bug while researching to answer https://support.mozilla.org/questions/1306939

Confirming as this seems to affect multiple users.

¡Gracias!
Alex

Status: UNCONFIRMED → NEW
status-firefox81: --- → affected
Ever confirmed: true

Hi
I reconize the same Problem after upgrading from Win 10 1909 to 2004. Upgrading to 20H2 did not solve it. Microsoft support did not know about.

Hi
I reconize the same Problem after upgrading from Win 10 1909 to 2004. Upgrading to 20H2 did not solve it. Microsoft support did not know about.

r

¡Hola!

Updating flags per https://support.mozilla.org/en-US/questions/1322320

¡Gracias!
Alex

status-firefox84: --- → affected

Confirmed STILL a bug on Windows 10 20H2 and Firefox 88. I find it amazing this hasn't been fixed yet.

Here to confirm this bug. No news??

90 beta - several entries of this bug. Not a new one!!!

Same problem on my yoga 260. I have been a Firefox/Thunderbird user for many many years and think both programs are the best. However the lack of the OSK popup is tending to push me towards a different product.

How many times... 91.0 - still the same...

Version 91 still the same with a tablet and w11. Try the extension FX OSK.

Another work around is to use the detached on screen keyboard. Only the non floating one has this issue.

Another thing is that it only does this when Firefox is fully maximized.

Can confirm this on Windows 11 (final) with latest Firefox ESR

Adding this issue persists in Firefox 93 on Windows 11 Pro 21H2.

Touching into the URL bar will not automatically bring up the touch keyboard, using the floating keyboard is unaffected but this is a cumbersome workaround.

Issue still here , FF 94.0.1 fresh install this evening on surface pro 3 running windows 10 Pro 20H2. This becoming tedious.

Same issue here. Was on Firefox ESR 91.0.3, tried upgrading to Firefox 94.0.2, still broken. Running Win11 21H2 on an HP ZBook Studio X360 G5.

Confirming that this bug persists on Firefox 96.0.3 on a Microsoft Surface Pro 7 running Windows 10 Home 21H1

I'm here to confirm this bug. It appears to persist still after a couple of years.

status-firefox104: --- → ?

This issue appears to be caused by an interaction with the "hidden task bar". As a work around disable "Automatically hide the task bar". I had this issue previously on a Surface Pro 3. I've upgraded to A Surface Pro 10 recently and the problem is gone. I can't recall, but I think if you move the OSK so that it doesnt open at the bottom of the screen, you may be able to reinstate the Auto hide taskbar feature.

(In reply to Greg from comment #24)

This issue appears to be caused by an interaction with the "hidden task bar". As a work around disable "Automatically hide the task bar". I had this issue previously on a Surface Pro 3. I've upgraded to A Surface Pro 10 recently and the problem is gone. I can't recall, but I think if you move the OSK so that it doesnt open at the bottom of the screen, you may be able to reinstate the Auto hide taskbar feature.
I recalled how to do this.....
To make the osk not open on the bottom of the screen, click the asterisked keyboard icon on top left of osk, by the microphone icon, then select the right hand icon in the second row, above the cog.

I just discovered this issue today. Unfortunately this gives me no other option than to switch to chromium for this application (it's the second time I have to use chromium, the previous time it was because I couldn't spawn several copies of firefox in kiosk mode, each on a different monitor).
FWIW it doesn't matter if the taskbar is visible or hidden, the firefox option to show an onscreen keyboard when necessary is set, as is the windows option to show an on screen keyboard when there is no keyboard connected.

Oh, and it's not the same as the original report (keyboard appering and disappearing at once), the keyboard doesn't appear at all.

Hey Luca, I just tested and the bug still persists for me and is exactly as described. You might have a slightly different problem; I'd recommend trying to troubleshoot further.

Whiteboard: [win:touch]

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.

(In reply to Greg from comment #29)

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.

I'm not on site now to check your suggestion, but edge in full screen managed to show the keyboard at the bottom of the screen with the taskbar hidden.

(In reply to calebgnz121 from comment #28)

Hey Luca, I just tested and the bug still persists for me and is exactly as described. You might have a slightly different problem; I'd recommend trying to troubleshoot further.

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.(In reply to Luca Olivetti from comment #30)

(In reply to Greg from comment #29)

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.

I'm not on site now to check your suggestion, but edge in full screen managed to show the keyboard at the bottom of the screen with the taskbar hidden.

I cant comment on Edge as I don't use it. The fix will allow you to remove the annoying behaviour that Firefox presents if you are set on using it in tablet mode configurations. Personally I recently switched to using Brave ( which is essentially Chrome sans spyware), as I was encountering frustrating web sites that were unusable when rendered by FF eg the interface to my router wouldn't work properly on FF. The HTML specification is ambiguous in places, which allows for different interpretations of rendering behaviours , and I believe most website developers develop and test against Chrome so I think browsers based on Chrome's engine are more likely to render true. Time will tell!

I mentioned edge because that's what was installed by default on the pc and I used it to see if the windows on screen keyboard settings were OK (and I'm not sure it's in tablet mode, it's just a mini-pc with a touch screen where I only connect a keyboard/mouse for setup and testing).
I'd much prefer to use firefox since I used it to develop and test the application (these pcs aren't going to show any random webpage, just my application), but I'm forced to use a different client because I also need the on screen keyboard to appear when an input field is selected.

(In reply to Greg from comment #31)

Personally I recently switched to using Brave ( which is essentially Chrome sans spyware), as I was encountering frustrating web sites that were unusable when rendered by FF eg the interface to my router wouldn't work properly on FF. The HTML specification is ambiguous in places, which allows for different interpretations of rendering behaviours , and I believe most website developers develop and test against Chrome so I think browsers based on Chrome's engine are more likely to render true. Time will tell!

¡Hola Greg!

Hope these lines find you well.

Please report such issues over at https://webcompat.com/

Hope this helps.

¡Gracias!
Alex

(In reply to Greg from comment #31)

(In reply to calebgnz121 from comment #28)

Hey Luca, I just tested and the bug still persists for me and is exactly as described. You might have a slightly different problem; I'd recommend trying to troubleshoot further.

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.(In reply to Luca Olivetti from comment #30)

(In reply to Greg from comment #29)

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.

I'm not on site now to check your suggestion, but edge in full screen managed to show the keyboard at the bottom of the screen with the taskbar hidden.

I cant comment on Edge as I don't use it. The fix will allow you to remove the annoying behaviour that Firefox presents if you are set on using it in tablet mode configurations. Personally I recently switched to using Brave ( which is essentially Chrome sans spyware), as I was encountering frustrating web sites that were unusable when rendered by FF eg the interface to my router wouldn't work properly on FF. The HTML specification is ambiguous in places, which allows for different interpretations of rendering behaviours , and I believe most website developers develop and test against Chrome so I think browsers based on Chrome's engine are more likely to render true. Time will tell!

Hi Greg, couple of things here.

  1. The OSK, even when set to dock to the bottom of the screen, is supposed to appear and persist when you select a text field. You can see this by testing in another application. This a firefox bug, and the suggestion you posted (using the keyboard in floating mode) is a viable workaround however not an indication that the bug does not exist.

  2. This is bugzilla, the tracking system for bugs with Mozilla software and here specifically for Firefox. It's really not appropriate for anyone to comment on a bug and tell others to go use a different browser regardless of experience. This is simply not the forum for that, people here are trying to improve and continue using firefox.

(In reply to Zac from comment #34)

(In reply to Greg from comment #31)

(In reply to calebgnz121 from comment #28)

Hey Luca, I just tested and the bug still persists for me and is exactly as described. You might have a slightly different problem; I'd recommend trying to troubleshoot further.

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.(In reply to Luca Olivetti from comment #30)

(In reply to Greg from comment #29)

This issue is not a bug. It is caused by the setting for the on screen keyboard, where the OSK appears at the bottom of the screen, interacting with "Hide the taskbar" . The issue is overcome by changing the OSK setting to have the OSK float in the centre of the screen. By using the small keyboard and wheel icon in the top left corner of the OSK, select the keyboard position icon that looks like a letter box rather than the one the looks like a set of drawers. Or turn off hide the taskbar.

I'm not on site now to check your suggestion, but edge in full screen managed to show the keyboard at the bottom of the screen with the taskbar hidden.

I cant comment on Edge as I don't use it. The fix will allow you to remove the annoying behaviour that Firefox presents if you are set on using it in tablet mode configurations. Personally I recently switched to using Brave ( which is essentially Chrome sans spyware), as I was encountering frustrating web sites that were unusable when rendered by FF eg the interface to my router wouldn't work properly on FF. The HTML specification is ambiguous in places, which allows for different interpretations of rendering behaviours , and I believe most website developers develop and test against Chrome so I think browsers based on Chrome's engine are more likely to render true. Time will tell!

Hi Greg, couple of things here.

  1. The OSK, even when set to dock to the bottom of the screen, is supposed to appear and persist when you select a text field. You can see this by testing in another application. This a firefox bug, and the suggestion you posted (using the keyboard in floating mode) is a viable workaround however not an indication that the bug does not exist.

  2. This is bugzilla, the tracking system for bugs with Mozilla software and here specifically for Firefox. It's really not appropriate for anyone to comment on a bug and tell others to go use a different browser regardless of experience. This is simply not the forum for that, people here are trying to improve and continue using firefox.

Zac, happy to concede this is a bug. Id draw to your attention that it was first reported 3 years ago, and appears to have surfaced earlier than that, so just how much improvement is the forum driving? As consumers we sometimes have to concede defeat and vote with our feet, but its important we say why.

From bug 1749484 comment 9:

RESOLVED: Latest Windows 11 Preview build (Version 22H2 Build 22621.382) on Surface Pro X. Microsoft must have patched the on-screen keyboard, it now works flawlessly in Firefox, no more disappearing keyboard glitch, it's seamless!

If you want to benefit from this you'll have to join the Windows Insider Program (at your own risk- you will effectively be a beta tester), I can confirm the build currently rolled out through the Preview Channel fixes this bug, cannot confirm for sure if the Beta Channel and Dev Channel work, but I assume so as they are newer builds than the preview channel.

Could anyone here confirm that this is indeed fixed by this new build of Windows?

See Also: → 1749484

I checked bug #1749484 and on windows 11 21H2 I don't see the same, the keyboard doesn't appear at all. I have to say that I run firefox in kiosk mode, I don't know if that's a problem, I can try in non kiosk mode to see if it makes a difference.
OTOH both chromium (in kiosk mode) and edge (normal mode, I don't know if it has a kiosk mode) have no problem in showing the keyboard on that same windows 11 21H2.
I cannot currently test 22H2.

I'm currently typing this using the OSK with the Taskbar hidden after recently updating Windows.

Firefox build 108.0.2
Windows version 22H2, OS build 22621.1105

It doesn't appear COMPLETELY resolved as Firefox patches a solution by changing the window size to be: (full screen - size of OSK). Reverting to a full screen window leaves the OSK to cover the bottom of the window. Using Firefox in full screen mode forces the window to stay full screen, and the OSK still covers the bottom of the screen. However, given the longevity of the bug, that I am not a software developer, I am using the software for free, and that my usability complaints are all but gone, I don't intend to come back and update this forum again.

Cheers to you all and shoutout to the real G's on the Firefox dev team.

I can reliably reproduce this on Firefox 110.0. My Windows version is 21H2, build 22000.1641. If I disable taskbar autohiding then the on screen keyboard is perfectly usable.

I will try to upgrade to Windows 22H2 to see if it somehow fixes the issue but I don't see the update available for my device for some reason.

Assignee: nobody → cmartin
Version: 77 Branch → Trunk

Alrighty -- I have been working on this issue for a while, and I have a bunch of things to report. I will break it
over a few comments to avoid one huge wall of text.

Steps to reproduce issue

  1. You must be using Windows 10 on a computer with a touchscreen (I'm using a Dell XPS).

  2. While in regular desktop mode, right-click the taskbar, select "Taskbar Settings", and ensure "Automatically
    hide the taskbar in tablet mode" is "On".

  3. Click the Notifications Menu icon in the lower-right of the screen and enable "Tablet mode".

  4. Open Firefox and ensure it's either full-screen or docked as half-screen.

  5. Tap the address bar or any web page with a text input box.

  6. Observe that the touch keyboard comes up, flashes, and suddenly disappears.

  7. Repeat with Firefox window docked half-screen and notice that the behavior is similar, but slightly different.

Some Microsoft software also suffers from this issue

Note that this is not a Firefox-specific issue -- Some Microsoft software also has this bug! For example,
open up Wordpad, tap anywhere in the writable area, and observe the same behavior.

The following Microsoft Windows software has been confirmed to have this issue:

  1. Wordpad

  2. Explorer.exe (tap in the address bar)

However, the following Windows software has been confirmed to not have this issue:

  1. Microsoft Store

  2. Notepad

  3. Registry Editor (address bar works fine)

  4. Feedback Hub

  5. Edge **

** All Chromium-based browsers (like Edge and Chrome) don't seem to suffer from this issue.

What Firefox is doing when the issue occurs

From investigation, here is the chain of events:

  1. User taps in an input box in the UI process or in a content process (content process will send a remote message to UI process)

  2. Firefox window procedure receives a WM_POINTERDOWN message

  3. That calls nsFocusManager::SetFocus()

  4. Which eventually ends up in a call to IMEStateManager::NotifyIME()

  5. Which eventually calls OSKInputPaneManager::ShowOnScreenKeyboard()

  6. Which calls the WinRT API Windows.UI.ViewManagement.InputPane.TryShow()

  7. After that, Firefox goes back to pumping messages.

  8. It quickly receives a WM_POINTERUP message

  9. That calls IMEStateManager::OnClickInEditor()

  10. Which eventually calls IMEHandler::SetInputContext

  11. Which again calls OSKInputPaneManager::ShowOnScreenKeyboard()
    and eventually the WinRT InputPane API above.

  12. And finally, calls the Win32 ImmAssociateContextEx()
    API

  13. We then see the keyboard appear, flicker, and disappear

Timers and intermittency

  1. Inserting a Sleep(100) in strategic spots seems to fix the keyboard issue

  2. Specifically, inserting sleeps before processing any more Win32 messages after calling
    ImmAssociateContextEx() seems to fix things.

  3. After making the call to TryShow(), we see several strange messages come through our thread's message pipeline:
    a "Message 96" that is sent to an UserAdapterWindowClass that seems to have been created on our behalf by
    COM, a "Message 49267" that is a user-defined message by Windows libraries with a nameMSUIM.Msg.Private that
    is dispatched to some unknown window, and a couple timer messages.

  4. Because this issue seems intermittent and is fixed by a delay, it seems reasonable to assume that it might be
    related to the timer messages.

  5. One such timer is setup in response to "Message 96", which is dispatched to
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc(). It makes a call to a function called
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_ScheduleBackupTimer(), which eventually calls
    something like this: SetTimer(msctf.dll!CThreadInputMgr::TimerProc, 1, 0, 0).

  6. After that, as soon as we call PeekMessage() again, a synchronous message forces us back to
    UserAdapter_WindowProc(), which calls SetTimer(msctf.dll!CThreadInputMgr::TimerProc, 1, 0x7fffffff, 0), effectively extending the timer to
    infinite... Why is this done? I have no idea, but I suspect it has something to do with trying to spy on the state
    of the message queue. Perhaps it provides information that GetQueueStatus()
    cannot?

  7. Other timers we see are setup during the call to imm32.dll!ImmAssociateContextEx():

    1. We see msctf.dll!CIMEUIWindowHandler::ImeUIWndProcWorker() make a call like
      SetCoalescableTimer(0x7D047E <MSCTFIME UI>, 1, 300, 0, 700).

    2. CoreMessaging.dll!Microsoft::CoreUI::Dispatch::DeferredUserDispatcher::DeferredScheduleDispatchCallback()
      makes a call like SetTimer(msctf.dll!CThreadInputMgr::TimerProc, 1, 0, 0), which looks very similar to what
      CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_ScheduleBackupTimer() was doing above.

    3. msctf.dll!CThreadInputMgr::_OnDocumentFocusChanged also calls msctf.dll!CThreadInputMgr::SetTimer, which
      does SetTimer(0, 0, 500, msctf.dll!CThreadInputMgr::TimerProc).

    4. We also see a SetTimer(0, 0, 100, msctf.dll!CThreadInputMgr::TimerProc)

  8. We can see from message processing logs that whether or not the keyboard stays up seems to be related to where
    the WM_TIMER messages end up relative to the messages around them:

  9. Another interesting thing of note -- Whether or not the keyboard will flicker and disappear is determined before
    the keyboard is even shown!

TabTip.exe

  1. While Firefox is calling IInputPane::TryShow(), we can see it is blocking on some kind of IPC to TabTip.exe,
    which makes lots of sense because that appears to be the executable that handles the touch keyboard.

  2. Based on all the observations above, I'm guessing that we're witnessing some of the plumbing for a COM Remote
    Procedure Call. I'm guessing Message 96 and UserAdapterWindowClass are probably there to marshall some important
    info between processes that use IME and TabTip.exe.

  3. If we debug TapTip.exe, we can see that the incoming messages end up at
    tipskins.dll!CIPTipWnd::ProcessWindowMessage().

  4. Note that even for applications that don't explicitly use IME, this is still called during tap events and focus
    changes. For example, the following messages arrive at tipskins in a plain app with a single input box:
    0x239, 0x23a, 0x420, WM_TIMER, 0x416. Note that the 0x4xx series messages don't have their usual meaning -- I
    cross-checked their wparam/lparam arguments against the respective RB_XXX, TBM_XXX, TB_XXX, TTM_XXX variants, and
    there is no one control class that seems to fit the bill. It's likely Windows is re-using these messages for
    an undocumented purpose.

Message Logs

  1. Here is an example of message order for Notepad (which seems to work properly):

    Message is 0x0000000000000239
Message is 0x000000000000023a
Message is 0x0000000000000420
Message is 0x0000000000000420 <-\
Message is 0x000000000000041f <-| Different from non-IME-app case
Message is 0x000000000000041e <-/
Exception thrown at 0x00007FFAFE7FAB89 in TabTip.exe: Microsoft C++ exception: long at memory location 0x000000ABDABFC384.
Message is 0x0000000000000113 <-- WM_TIMER
Message is 0x0000000000000416

  2. Here is an example of message order for Edge (which also works properly):

    The message is 0x0000000000000239
The message is 0x000000000000023a
The message is 0x0000000000000420
                                    <-- There was another 0x420 here for Notepad
The message is 0x000000000000041f
The message is 0x000000000000041e
Exception thrown at 0x00007FFB370ECF19 in TabTip.exe: Microsoft C++ exception: long at memory location 0x000000CD4F5FC604.
The message is 0x000000000000c1c8 \ Different from Notepad. The keyboard appears after the 0xc1c8 is handled.
The message is 0x000000000000041e /
The message is 0x0000000000000113 <-- WM_TIMER
The message is 0x0000000000000416

  3. Here is an example message order from Firefox (where the keyboard shows and then disappears):

    The message is 0x0000000000000239
The message is 0x000000000000023a
The message is 0x0000000000000420
                                  <-- Notepad had a second 0x420 here
                                  <-- Notepad and Edge had a 0x41f here
The message is 0x000000000000041e
Exception thrown at 0x00007FFB370ECF19 in TabTip.exe: Microsoft C++ exception: long at memory location 0x000000CD4F5FC604.
The message is 0x000000000000c1c8 \ Different from Notepad, but same as Edge
The message is 0x000000000000041e /
The message is 0x0000000000000113 <-- WM_TIMER
The message is 0x0000000000000416
The message is 0x000000000000041f \ RIGHT HERE. These two messages are not in Notepad or Edge's logs. The keyboard
The message is 0x000000000000041e / disappears right after the 0x41f message is handled.

  4. Confusingly, here is a sequence from Wordpad (which is broken, but it looks very different than Firefox):

    The message is 0x0000000000000239 \
The message is 0x000000000000023a |
The message is 0x0000000000000420 |
The message is 0x0000000000000420 | All identical to Notepad
The message is 0x000000000000041f |
The message is 0x000000000000041e /
Exception thrown at 0x00007FFB370ECF19 in TabTip.exe: Microsoft C++ exception: long at memory location 0x000000CD4F5FC604.
The message is 0x0000000000000113 \ Also same as Notepad
The message is 0x0000000000000416 /
The message is 0x000000000000c028 \
The message is 0x000000000000c1bf |
The message is 0x000000000000c028 | No idea what's going on here, but it disappears at some point in this sequence
The message is 0x000000000000c1bf |
The message is 0x0000000000000113 /

Current state

  1. So, it would be very nice to be able to find out what is causing those 2 extra 0x41f, 0x41e messages in
    Firefox's logs. I already tried debugging Firefox while TabTip.exe is processing those messages, but
    unfortunately there doesn't see to be any Firefox thread blocked waiting. This must mean that either those
    messages were already posted during an earlier Firefox action, or they are coming from within TabTip.exe, or
    they are materialized into the message queue by Win32k.

  2. I attempted to collect ETW logs, and I was able to see TabTip.exe dequeue these messages, but I was not able
    to see where they were enqueued in the first place.

  3. One possibility is that I noticed that TabTip.exe receives some notifications anytime keyboard focus changes.
    It's possible that we're interfering with that while we're handling some other window messages, such as window
    resizing. For example, this bug doesn't seem to happen if the touch keyboard is set to floating mode -- Only if
    it's set to occupy space on the screen (forcing Firefox to resize).

  4. It's also possible that some of those timers that are kicked off by the various Windows DLLs don't expect certain
    API calls to be made before they've resolved, and we are making those API calls.

  5. I'm going to walk away from this for a while, but I believe Yannis is thinking of poking around at it for a while.

  6. If Yannis also gets stuck, it might be worth asking for some help from Microsoft.

You need to log in before you can comment on or make changes to this bug.