I'm not sure if there's a setting I'm missing which would correct this behaviour. Let me describe what happens with sandboxed Firefox, but it could equally apply to other sandboxed programs.

I have program-specific mouse button settings (for wheel-button, X1, X2) on some programs, but not Firefox.

When I:
1/ run Firefox sandboxed
2/ transfer focus to (non-sandboxed) program XXX which has specific mouse button settings
3/ switch focus back to sandboxed Firefox
then the mouse button settings for program XXX remain "stuck" and their key sequences are sent to sandboxed Firefox.

A way to clear stuck button settings is to click away to another program (or the desktop/taskbar) which has no specific mouse button settings, then take focus back to sandboxed Firefox.

On the off-chance I tried tinkering with the BlockFakeInput setting, but to no avail.

SBIE v2.86, XP SP2 Home

Okay, well, I implemented a workaround via an AutoIt3 script which watches for window focus changes. When focus returns to sandboxed Firefox it instantly switches focus to the Windows taskbar and back again to Fx, thereby clearing the stuck mouse button settings.

But it would still be nice to know if there's anything else I could change config-wise to prevent the problem in the first place.

Thanks

If you can tell me how to reproduce the problem, that is, how to define such bindings, I can try to look into it. But please try to be elaborate because I have no idea how to do it.

I dont know exactly how hes doing it, but im pretty sure he is using the program AutoHotKey (http://www.autohotkey.com/), when he said, "Okay, well, I implemented a workaround via an AutoIt3 script" that was a dead give away seeing as that is used by AutoHotKey.

Sure, but it's beginning to occur to me that it might possibly be mouse-driver dependant. I'm using MS IntelliPoint v4.10.0851 (mouse driver v11.40) on the two XP machines demonstrating this behaviour. I know that's an old version but a later version withdrew certain key-sequences I needed (such as ESC) from the program-specific button setting options, and the version I use has always worked fine. To access the button assignments it's simply Control Panel -> Mouse and there they are on the first tab.

To reproduce (assuming button assignments are available), for example:
1/ Create a program-specific button assignment for the Wheel Button (middle mouse button) for NOTEPAD.EXE, setting it to Ctrl-A
2/ Open Notepad non-sandboxed
3/ Open Firefox in the sandbox
4/ Click onto the Notepad window
5/ Click back onto the Firefox window
6/ Click on a webpage link with wheel button / middle mouse button
7/ Instead of opening the link in a new tab (expected behaviour), Firefox now "selects all" (i.e. Ctrl-A behaviour carried over from the Notepad-specific setting)

If you find it impossible to reproduce, for whatever reason, then I can live with my workaround. But having noticed the BlockFakeInput setting I thought the behaviour might somehow be a corollary of SBIE intermediating in the device input stream.

I'm not using AutoHotkey. AutoHotkey may have been a derivative of AutoIt2, but AutoIt3 is an altogether different beast. (And this forum is not the place for the traditional spats between AHK and AU3 supporters ). I simply mentioned that I had set up an AutoIt3 wrapper to spot window focus changes from/to sandboxed Firefox in order to overcome the "stuck mouse button setting" syndrome.

FWIW I do use another, totally different, hotkey launcher program but those hotkey sequences are all completely different (Ctrl+Alt+<char>) and anyway the problem described here persists when that - or any other - hotkey prog is not running.

Yep your right, AutoHotKey is a derivative of AutoIt2, although the newer versions of AHK seem to be able to read AutoItv3 scripts, which is where i got confused, lol, anyways i always thought Autoit was better than AHK but not as powerful, i guess ill have to re-evaluate autoit, ill test autoit and see if i get the same problem as you.

Just to clear up any confusion here, AutoIt3 is not the cause of the problem. The AU3 script I'm now using is the workaround solution!

The stuck mouse setting behaviour happens when no AU3-based progs are running at all.

So tell me then what program are you using to create mouse and keyboard hotkeys, something like StrokeIt?

For keyboard hotkeys http://www.pssoftlab.com/pshl_info.phtml as recommended by "Gizmo" (along with AHK ) at http://www.techsupportalert.com/best_46_free_utilities.htm#25. But as I said earlier, this could be not running and the problem would still manifest itself.

For mouse button sequences, Microsoft Intellipoint. See my earlier post.

This, along with your earlier description, tells me I can't actually reproduce this.

My first tab on the Mouse control panel is called Buttons and is pretty standard:

Button configuration
Double-click speed
ClickLock

Okay, well, thanks for your attention. SBIE's a great tool, and I have a satisfactory workaround. I have a small suspicion that the problem may be related to COM....