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.
Related
I get list of windows with Win32.EnumWindows and then filter them to keep the ones I want. I want to keep the normal, visible Skype window and skip the hidden Microsoft Edge window. (I use Chrome, and no accessible instances of Edge are visible in my Alt-TAB output or on my screen.)
I already filter out a few Edge windows that are of class Windows.UI.Core.CoreWindow but there is one Edge window still in the list. Maybe it is a main or parent window or something? Maybe the Task Manager window or the Settings windows that I have open are Edge underneath the hood?
I dumped the properties of both Skype and Edge windows, and they are the same for the items that I looked at. (I recognize that having WS_VISIBLE set does not mean that I get to see the window.) Here are the items that are identical for both windows.
Skype window: (Identical to the output for the Edge window that I can't see.)
Is visible.
Has no owner.
Has no parent.
Is not APPWIN.
Is not a toolwindow.
Is not a cloaked store window.
Class is ApplicationFrameWindow
Could anyone give me an answer on how to identify the Edge window (other than by using its name as a special case in the code) as distinct from the Skype window? Or maybe point me to a web article that I haven't seen yet? (I have looked at a dozen or so, without success.) Thank you.
Thank you everyone for your help. I ended up using the window titles because I found that there were several windows on my list that did not show up in the normal Alt-TAB display. Special cases were always required (on the net examples) to remove them from the list to help match the normal Alt-TAB display. Once I accepted the need for special cases, then using the title was the easiest way for these two windows.
I also learned that Microsoft Edge (and probably other apps too) start-up some background processes and windows even if you are not using them. Someone on the net said that you could disable these background processes in Settings, so I did that to get rid of some unwanted windows on my Alt-TAB (or nearly Alt-TAB) list.
I am currently researching how to spot windows (like Edge and Settings) that have IS_VISIBLE windows (that you can't see, but that have all the attributes mentioned earlier in the original question) attached to background processes that don't show up in the Apps list in the Task Manager.
Very strange. The OS obviously knows how to spot those windows and keep them out of the Task Manager Apps list and the Alt-TAB display. I wish I knew how to do it. Maybe the answer lies with processes, as Rita said earlier (but I didn't see any example of that method in my net research). Even Raymond Chen's famous method of walking ancestors does not produce the right answer that matches the Alt-TAB display.
A little background
Our application (AppA) is calling a 3rd party application (AppB). We are simulating AppB's window as being modal to our application.
pseudo
while AppB_Running
If AppA_focused
SetForeGroundWindow(AppB_Hwnd)
HandleMessage
SetForegroundWindow(AppA_HWnd)
This has been working for years without incidents, that is, until we started rolling out Windows 10. We started receiving reports that a random app (AppC) was sometime getting the focus when we closed AppB (Actually, given our user's tech expertise, the report were more along the line "Closing AppB kills AppA" but I digress). That behavior can be reproduced occasionnaly(<5%) on dev machine (But not yet while debugging...)
So far, test result suggest AppC is the application that had the focus before AppA.
Is there a way I can ensure AppA gets the focus back when AppB closes?
Extra notes
The problem can be reproduced even if AppA only ever loses focus to AppB. (AppC never being focused after AppA started)
While this does not directly answer my original question, it does give some more insight on the problem and might be useful to someone else.
Part of the issue was an oversight on our end. More specifically, the way we obtained AppB_HWnd. We basically picked the first top level window we encountered. In our current test case, that window happens to be an invisible windows ('MSCTFIME UI'). Calling SetForegroundWindow on an invisible window doesn't seem to cause problems per se, Windows seems to just bring to front one of the process' visible window. It is when said process does not have any visible windows left that things seems to go awry. That usually happen in our case between the moment AppB's main window is closed and the moment the process ends.
So... Don't call SetForegroundWindow on an invisible window
As for why we didn't have any trouble in Win7? Maybe the first window was always a visible one. Or maybe SetForegroundWindow behaved differently back then.
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.
I am using BitBlt heavily in my project. I create a number of threads and in each thread I capture the screen by BitBlt. It works great and as expected for now except the following problem.
The problem happens when the user clicks on a running program or for example already opened explorer on the taskbar. You know when you click on the running program on the taskbar, it either minimizes or appears on the screen. The issue that I am talking about happens just in this transition. At that moment, something like an interrupt, all threads stop capturing the screen for a fraction of a second and then they continue capturing. The same thing happen when you move down or up the thing on the volume control window. Could you please shed some light why this is happening and how I can prevent this happening?
Thanks.
Jay
It could be a scheduling issue. When you activate an app, it gets a small, momentary boost in its priority (so that it can seem responsive in the UI). This boost might last about as long as the animation and momentarily pre-empt your screen capture threads.
It's also possible that the desktop manager is serializing stuff, and your bitblts are simply stalled until the animation is over. Even if you've turned Aero off, I believe the desktop window manager may still be in compositing mode, which has the effect Hans Passant was describing in the comments.
If you're trying to make a video from the screen, I think it's going to be impossible to rely on GDI. I strongly suggest reading about the Desktop Window Manager. For example, this caveat directly applies to what you're trying to do:
Avoid reading from or writing to a display DC. Although supported by DWM, we do not recommend it because of decreased performance.
When you use GDI to try to read the screen, DWM has to stop what it's doing, possibly render a fresh copy of the desktop to video memory, and to copy data from video memory back to system memory. It's possible that the DWM treats these as lower-priority requests than an animation in progress, so by the time it responds to the BitBlt, the animation is over.
This question suggests that DirectShow with a screen capture filter might be the way to go.
A quick Google search for solutions to Focus Stealing in Windows reveals two main result categories:
People suggesting incomplete solutions involving the
ForegroundLockTimeout registry entry (or TweakUI, which I believe simply changes the aforementioned registry entry),
which isn't very effective.
Incessant hordes of Windows users complaining about it.
It's particularly annoying in two common scenarios:
Something triggers a program to popup a dialog window in the background while a fullscreen app is focused, causing the fullscreen app to minimize.
A window steals focus while you are typing, stealing all of your keystrokes. If you happen to press Space, Enter, or trigger a keyboard shortcut (like Y for Yes), it can cause completely undesirable outcomes.
What creative solutions can be applied to fix this problem for either or both of these scenarios?
I have one suggestion for how it can be solved, but I cannot implement it completely since I lack the knowledge.
The focus change between windows have to be instigated by the offending program calling a Windows API function located most probably in shell32 or user32. Some progams, like Adobe Photoshop makes the call multiple times (at least twice) to force itself up on the user when it's starting. The idea is to hook into this API function (if possible) and check where the call originates from. If it's not from explorer.exe (i.e. Alt+Tabbing or clicking an icon on the taskbar), then call should be blocked by said hook.