Duplicate screenshots acquired in case Keymap preflet is opened.

[damoklas]

How-to reproduce: 1) Open home folder. Check for existing screenshot PNG files. 2) Open Keymap preflet. Press the PrintScreen key.(Note that Keymap window must be active.) 3) Note that dublicate scrrenshot1.png and screenshot2.png were acquired.

[damoklas]

And if make alt+V to Keymap preflet in "Sample and clipboard:" that write dublet.

[anevilyak]

This looks like an app_server bug, the BWindow is receiving those keyboard messages twice (and consequently invokes printscreen and/or the shortcuts twice), which is probably an error in handling SetEventMask(B_KEYBOARD_EVENTS);

[axeld]

I don't think the app_server is to blame here; when the keyboard view is the active view, there should only be one screenshot. Otherwise, since the focus handler is different from the SetEventMask() handler, it should send two messages.

So the fault is obviously in BWindow, as it does not detect this case (it should only consider focus messages).

[pulkomandy]

There is a problem here :

• Create a window with a view inside, the view has SetEventMask(B_KEYBOARD_EVENT);
• Add a PrintToStream in the window MessageReceived or DispatchMessage
• Unfocus the window
• Notice it still gets ALL keyboard events

Of course, the window will intercept some of them : screenshot, deskbar switcher, command Q. These were meant to be handled once by the focus view, now they are handled twice (by the focus window and the seteventmask one).

More interesting : it's super-easy to make a keylogger and grab passwords and other useful info, as all of this gets (at least) in BWindow::DispatchMessage even when the window is not focused.

I'm not sure the window should get these messages at all when it's not focused ? The Be Book doesn't seem to tell about it. Anyway, that's a rather critical security problem :/

(btw, thanks to Duggan for help tracking it down)

[anevilyak]

The whole point of that function is to be able to get those events regardless of your focus state. In any case, it's the least of our concerns as far as security goes, and a key logger could just as trivially be done via e.g. an input server filter. The problem isn't that the API allows writing one, that's true on all OSes, it's more a matter of how easily it can be installed without the user noticing.

[pulkomandy]

Well, depends on what "all the events" means. It's not clear from the BeBook if it's only events sent to the window, or really everything. I'm not sure getting everything this way is useful ? Is there an use case for it ? It also creates more messages and the original bug reported here. All use cases I can come up with beside the keylogger would rather be made with input_server add-ons, so I'm wondering what's the purpose of dispatching that way ?

[anevilyak]

It works the same way on hrev5, try for yourself. In any case, keymap uses it in order to animate the keyboard always, and textviews use it to see how far outside the view the mouse is in order to do things like faster scrolling if you move the mouse further away. Those aren't the only possible uses either.

[pulkomandy]

Well it doesn't work for the keymap preferences then. It doesn't do anything when the window is unfocused. As for textviews, I don't see how this can happen without the view's window being focused. So I still don't get the point.

It makes sense as long as the window is focused, but I don's see why it has to grab input from every window out there, especially for the keyboard (ok, mouse can be "useful" for an xeyes or similar app...)

[axeld]

It's not supposed to grab input, it's supposed to get it as well. And it's the only way to get a shortcut outside of your application's focus without installing an input server add-on -- and it was the same way in BeOS.

[axeld]

Could this be fixed with hrev50033?

[waddlesplash]

It is indeed! PrntScrn with Keymap focused no longer gets two screenshots, just one.