Opened 8 years ago

Closed 11 days ago

#5393 closed bug (fixed)

Duplicate screenshots acquired in case Keymap preflet is opened.

Reported by: damoklas Owned by: nobody
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (12)

comment:1 Changed 8 years ago by damoklas

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

comment:2 Changed 8 years ago by anevilyak

Component: Preferences/KeymapServers/app_server

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

comment:3 Changed 8 years ago by axeld

Component: Servers/app_serverKits/Interface Kit

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

comment:4 Changed 7 years ago by 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)

Last edited 7 years ago by pulkomandy (previous) (diff)

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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 ?

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by 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...)

comment:9 Changed 7 years ago by 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.

comment:10 Changed 16 months ago by axeld

Could this be fixed with hrev50033?

comment:11 Changed 16 months ago by axeld

Owner: changed from axeld to nobody
Status: newassigned

comment:12 Changed 11 days ago by waddlesplash

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.