164084 - moz disturbs mswin event queue

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[kill this account]

Does anyone know if it is really safe to reorder the event queue like this?

http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsAppShell.cpp#94

 94 BOOL PeekKeyAndIMEMessage(LPMSG msg, HWND hwnd)
 95 {
...
110     return ::PeekMessage(msg, hwnd, lpMsg->message, lpMsg->message, PM_REMOVE);

From my read of Microsoft's documents this seems to be counter to their design:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/MessagesandMessageQueues/AboutMessagesandMessageQueues.asp

  A thread's message loop must include TranslateMessage if the thread is to 
  receive character input from the keyboard. The system generates virtual-key 
  messages (WM_KEYDOWN and WM_KEYUP) each time the user presses a key. A 
  virtual-key message contains a virtual-key code that identifies which key was 
  pressed, but not its character value. To retrieve this value, the message loop 
  must contain TranslateMessage, which translates the virtual-key message into a 
  character message (WM_CHAR) and places it back into the application message 
  queue. The character message can then be removed upon a subsequent iteration of
  the message loop and dispatched to a window procedure. 


If bug 132759 and/or bug 157144 makes sure that gecko always responds promptly to
user input we should at least discuss whether we should remove the code that
reorders the message queue.

Comment 1

[[e-mail]]

> b1 = ::PeekMessage(&msg1, NULL, WM_KEYFIRST, WM_IME_KEYLAST, PM_NOREMOVE);
So in fact all key messages will be reordered, including translations.

I'm no PeekMessage guru so initially I was wondering if this technique could be
used to boost the priority of other messages (mouse, paint) to make Mozilla more
responsive but I now see that you've come up with an alternative solution.

Comment 2

[kill this account]

Back in 1992 Microsoft designed the event queue so that Post messages have
priority over input. This was a very poor design choice to solve a specific
problem. They solved a specific problem with a general solution that clearly
has unwanted side effects: UI events are not 1st priority.

Moz developers have be fiddling with windows event queue reordering for a while 
now.

The problem with just fixing input event starvation with a peek here in the
the main event handling loop in nsAppShell.cpp is that Microsoft does a nasty 
thing:

  During window resizes/moves Microsoft has a loop inside DispatchMessage
  that reads the queue in natural order. In this case we have no way to
  to prioritize the input events over the post events (reorder the events).

This means that if some part of the application  uses PostMessage to request 
CPU (like a Flash plugin) and it can use 100% of CPU (like a Flash plugin)
then the input event will *NEVER* be serviced. What makes this catastrophic
is that during a window resize/move Microsoft grabs *all* input events and ONLY 
sends them to the application being resized/moved. This application is of 
course unable to get the input events.

Thus: ALL USER INPUT IS FROZEN TO *ALL* APPLICATIONS

At this point the only thing I have found that works is Ctrl-Alt-Delete. Once
the dialog comes up one can just kill moz and continue on with other
applications. I suspect however that most users will assume they have to reboot
which could make them lose data in other applications.

This is why I've taken a different approach in bug 132759.  I am lowering the 
priority of plugin events (currently Flash) below all OS events if they are 
being starved. I do this by defering them to a timer which is lower than 
input event. This works even when Flash is using 100% of CPU and the user is 
resizing/moving the window.

In bug 157144 Kevin lowers the priority of moz events (eg: table reflow) below
all input events if they are being starved. He does this by putting them on a
timer.

Rather than filtering the queue to push up input events I believe we should
push non-OS post messages down. This would leave the OS events in natural
order.

Comment 3

[[e-mail]]

Thank you for your very clear explanation.
Now I understand about subclassing plugins and delaying posted events.

Comment 4

[Markus Hübner]

This problem regularly comes up - has there been any progress in the meantime?

Comment 5

[Pham]

.

Comment 6

[Ere Maijala (slow)]

So Flash is not a problem anymore, right? Do we still have the problem somewhere
else or could we now just stop disturbing the event queue?