I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
Related
I'm testing my WebRTC app in Firefox, and it appears that Firefox is not gathering ICE candidates unless and until the Firefox window is in focus?! When using two separate browser windows on the same machine, one of them is obviously always not the frontmost window. The log tells me that Firefox stalls at the point where it's supposed to start gathering ICE candidates, until I explicitly click on the window to bring it into focus, at which point is starts candidate gathering and shortly after establishes the connection. I can switch windows any time after the process has started, it will finish successfully; but the window apparently must be in focus at the start of the process.
No such behaviour on Chrome, it always gathers candidates in any state.
Is this a known behaviour? Is there a rationale for this, or is it a bug?
Firefox 44.0.2 on OS X El Cap
Hidden tabs or windows in Firefox cannot turn on the camera. Personally I feel a bit safer knowing that.
Even if you've chosen "Always Share", the camera wont activate until you focus the window.
From the comments it sounds like this is what's happening in your case.
In contrast, this fiddle works fine from two tabs, because only the page where the user presses a button (the sender-side), accesses the camera.
This code section intentionally left blank.
Never mind, it wasn't the ICE candidates, it was getUserMedia which blocks unless Firefox is the active window. The asynchronous nature of my code made this less apparent than it should have been. This behaviour is apparently by design and is described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1195654.
I am implementing a Cocoa application which supports the fullscreen mode. If the user quits while working on the fullscreen mode, I need to start the application in fullscreen mode,
While starting the application I check whether the application should start in fullscreen mode then call the toggleFullScreen: on NSWindow. Then the, application goes to the fullscreen mode and comes back to the normal window mode.
User can go to the full screen mode while working without any problem. Any tips on what's going wrong on this?
Make sure you really want to do this. Since Lion, there is a window restoration API that you should be using. See Any NSWindowRestoration examples? for how to use it. The caveat is that if "Close windows when quitting an application" in System Preferences is checked (which it is checked by default since 10.8), the window can only be restored upon reboot if the user chooses to do so.
If the user did not opt in for the window restoration setting throughout the OS across quitting applications, then generally you do not have to expect the window of your app to be restored for them. However, if you think you have a good reason otherwise, then I suggest invoking toggleFullScreen: after windowDidLoad: is called. I can only guess that you're calling it too soon and the window autosave might get in the way. It'd be helpful if you showed the relevant code.
Regardless, you should be implementing window restoration anyway and in the case of the window being restored by the API, you simply don't do anything.
When Im debugging my app in VS2012 and it crashes, the input (mouse and keyboard) starts to lag extremely, the fps drops to about 0.3 or less and I can't even move my mouse without waiting 3 seconds... The only solution is to do Shift-F5 which will end the debugging, and everythng is fine then again.
Whats more interesting, the only lagging thing is the input, the whole background works perfectly fine, text caret is blinking at normal rate and tooltips are nicely animated when mouse gets over a button.
Im compiling the project with allegro 4.2 (I have to use it, it would take too long to explain why).
I have no extensions, a pretty fast pc which should be able to handle debugging...
Im interested in any solution, it may be dirty/hackish... I can of course provide more information if needed.
Thanks for any help.
EDIT: Reading through forums I found some information about the "Auto" window or something like that (don't remember exactly and can't find it anymore), which is doing some "background tasks" and that causes lags... Do you think running it on separate core would fix that?
A tale of multi-second stalls when hitting a breakpoint, related to the raw input API: http://the-witness.net/news/2012/12/finding-and-fixing-a-five-second-stall/ (archived)
It's a very long time since I last saw this sort of thing myself, but I seem to remember that the culprit in my case was DirectInput. (This makes some sense, given the tale above, as DirectInput has long been a wrapper over the raw input API.) And I think the solution was to use the emulated keyboard and mouse devices rather than the default ones, which you do this by passing in one of the emulated device GUIDs to IDirectInput8_CreateDevice. Discussed briefly here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416845%28v=vs.85%29.aspx
(I don't remember whether cooperative and exclusivity levels made a difference - it might be worth trying changing these too.)
I recently experienced the following similar issues while debugging a game:
Hit a breakpoint, halting the program for debugging.
Pressing any key now takes around 1 second to "process". It will be buffered and sent slowly one after another to whatever window is now active.
In my case, the application installed a low level keyboard hook with SetWindowsHookEx(WH_KEYBOARD_LL, ...). After removing this (for !NDEBUG builds only as you wish), the input lag was gone.
I suppose the hook cannot respond at all while your application is halted, and eventually the system skips it after a timeout, which length can be configured in milliseconds under HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout:DWORD as mentioned here. In fact, the link in the accepted answer mentions this issue, but I thought I explain the core of it right here, also because the link went dead before I fixed it.
Try to find such a hook in your application or dependencies, and check if removing it helps. Since you mentioned this happens to your mouse too, check for a (low level) mouse hook (WH_MOUSE_LL) aswell. The available hooks are listed on MSDN.
I have a cross platform Qt application that's running into some trouble in OSX. There's a feature that OSX has that I didn't even know existed - the 'Help' key. My MBP doesn't have one, and neither does my Apple wired keyboard purchased a year ago. It seems that this is mostly something that older Macs have. Apparently it generates the same scan code as the Insert key on PC keyboards.
Anyways, when the Help key is pressed, the cursor over our application (or any application that receives the Help key event) turns into a little question mark. This seems to be part of what's called 'context-sensitive help mode', as documented in the NSHelpManager's setContextHelpModeActive: method and in the NSApplication's activateContextHelpMode: method docs. From the docs:
In this mode, the cursor becomes a question mark, and help appears for any user interface item the user clicks.
Most applications don’t use this method. Instead, applications enter
context-sensitive mode when the user presses the Help key.
Applications exit context-sensitive help mode upon the first event
after a help window is displayed.
How many Cocoa developers actually know about this? I'm assuming that clicking on something in the application with this question mark cursor should do something like bring up a help message, but I haven't found a single Cocoa application where it actually does anything at all - not even Apple's apps do anything. In fact, it even seems to put a lot of applications into a strange mode where the cursor text selection is enabled.
The problem is that when we change the application cursor programmatically in Qt when we're in this help-question-cursor-mode, bad things happen. Specifically, our application actually crashes. The crash happens deep inside Cocoa in the NSApplication's NSHelpManager. I'd like to find out why we're seeing this crash, but I'm actually more interested in how we can suppress this 'help' mode. There's nothing in Qt or Cocoa that I can see that would stop it, other than perhaps intercepting and squashing an event, which I haven't tried yet.
Does anyone know any more about this?
What am I doing wrong here? :(
I open Instruments.app, create a new UI Recorder template, select my application's .app bundle from the Target -> Choose Target menu, hit Record, open a couple of documents, type some stuff on them, close the documents, quit the app.
At this point UI Recorder stops and the Record button changes to "Drive & Record". I hit it, I see my application get launched and Instruments start recording data. Then Instruments gets confused (somehow)... my application loses focus, and suddenly UI Recorder is replaying all of my actions in Instruments!!, which just screws with Instruments in all kinds of messy ways. In this state I'm unable to move the mouse (the system just steals the cursor back), and I'm unable to quit instruments, since when I hit CMD+Q I'm prompted to Save the document, which I can't do because I have no control of the keyboard or mouse.
This is really frustrating. Has anyone got experience with this tool who can tell me where I'm going wrong? I'm scared to run it a third time as it literally hijacks my entire system.
So, you have a memory leak, and it happens when you do a specific series of actions.
The hard way to debug this would be to just have the Allocations and/or Leaks instruments and do the actions yourself every time, and every time you screw up (leave something out, do something wrong), kill the process and start over.
The easy way is the UI Recorder.
The first time you record with it, it records your actions (at the events level, not the target-action level). Mouse movements, clicks, etc.
The way UI Recorder differs from other instruments—which is why it surprised you—is that when you record with it thereafter, it plays them back.
It's not just swinging around your mouse cursor willy nilly; it's doing what you did the first time. Every time after you do things the first time, the UI Recorder does the exact same things for you.
That's what UI Recorder is for: Perfect, mechanically-ensured reproducibility. It's doing what it's meant to do; it's working as it should.
And yeah, aborting that is hard. I haven't looked yet, but there may be a stop-recording global system hotkey you can use. There is one when Instruments is in mini mode.
Also, you can set whether UI Recorder is in “drive” (playback) or “record” mode in the little pop-over that comes up when you click on the (i) button for the instrument. Switch it to record mode to re-record your interaction for different results in future runs. (I don't know whether it preserves the recording(s) in past runs.)