Since xCode updated i'm having trouble running any ui test case. It gives me this error when its expected to do a simple tapping action for example:
XCUIApplication *app = [[XCUIApplication alloc] init];
XCUIElement *passwordSecureTextField = app.secureTextFields[#"Password"];
[passwordSecureTextField tap];
Anyone have any ideas why am i getting this error? I've searched on google and here but haven't found any solutions.
Thank you.
Make sure you don't have any animations on screen during UI Automation tests. We had a text alert flashing on the login screen for debug/test builds of our app, and it would cause the "failed to quiesce" error until it was removed.
There are some other posts about this error that mention issues with UIRefreshControl, so I would suspect animating that or UIActivityIndicatorView would cause the same problem.
It might help to turn on the "All Exceptions" breakpoint. I used it and I recall getting the same error. It will break at the line with the problematic code and should show you the stack trace of the error with more info.
I had a similar error - as well as the simulator running very slowly. In my case it was fixed very simply by the method given in the accepted answer here: Xcode simulator extremely slow.
To save you a click: The issue was that I had accidentally pressed Cmd + T at some point, enabling "Slow animations".
I had to turn off the "Personal Hotspot" in order to get a working test environment (Because the blue bar in the top apparently disturbed XCTestRunner)
But as some tests need internet connection I can't do testing when being in the wild:-(
Anthony F's answer says it all. Likely something is still animating. The system seems to wait for the app UI to "settle" (go idle) and when that happens, it performs the tap action. However, when the UI constantly runs animations, it will never settle.
Xcode Console Output
Enable the console output in Xcode to see what happens when running the test.
Below is an example of the log, when it works well. The system waits for the app to go idle and when that has happened, it goes to find the button in the hierarchy.
t = 16.95s Tap "#go" Button
t = 16.95s Wait for app to idle
t = 17.00s Find the "#go" Button
t = 17.00s Snapshot accessibility hierarchy for XXX
t = 17.09s Find: Descendants matching type Button
t = 17.09s Find: Elements matching predicate '"#go" IN identifiers'
t = 17.10s Wait for app to idle
t = 17.15s Synthesize event
t = 17.41s Wait for app to idle
Below is an example when it fails. The system waits for the app to settle so that it can look for the button in the hierarchy. Since, it does not settle, it waits "forever" finally running into the timeout.
t = 18.88s Set device orientation to Unknown
t = 18.93s Tap "#go" Button
t = 18.93s Wait for app to idle
t = 79.00s Assertion Failure: UI Testing Failure - App failed to quiesce within 60s
In my case the "failed to quiesce" was caused, because at time t=18.90s, demo data was generated which caused repeated updates of a UIProgressView. From then on the app UI never settled ("quiesced").
("quiesce" as a word is not in my active vocabulary, which certainly has delayed my recognition of what was going on. The console output pushed me into the right direction. I'd bet "idle" rings more bells than "quiesce" for many developers.)
Related
I'm working on a Unity project for Hololens, that uses the camera to capture pictures, send them to a photo recognition API and displays the result. The project works perfectly fine in unity, but not on the emulator/Hololens.
Unfortunately, I wrote a lot of code at once, so i don't know at what point this problem started. The problem show's up after building the project and running it on the Hololens/emulator in Debug mode. On the Hololens, I see the starting window (the one you see after you open any application). After i place it, i see End showing splash screen. on the Output window in Visual Studio, and it just doesn't go any further (but doesn't freeze either, just does nothing).
I don't know where it's coming from, since no exceptions are thrown, but i suspect the camera is the cause. Earlier, i had to comment this line of code:
transform.position = Camera.main.ScreenToWorldPoint(new Vector3((CameraManager.Resolution.width * .5f), (CameraManager.Resolution.height * .5f), 10));
because the function ScreenToWorldPoint was throwing the following exception:
Screen position out of view frustum (screen pos 0.000000, 0.000000, 10.000000) (Camera rect 0 0 0 0)
As you see it says that the Camera rect's size is 0. I even tried directly logging the camera's dimensions to make sure (Debug.Log(Camera.main.pixelWidth + ", " + Camera.main.pixelHeight)), and sure enough, they were (0, 0) on the Hololens/emulator.
I made sure that webcam is supported, and that my camera settings are all set, but that didn't help either.
So i'm not sure if that's the cause of the problem or simply a symptom. And I can't start anywhere since neither the Output nor the Error window show anything wrong. Any help or suggestions would be greatly appreciated.
Thanks for reading!
Edit: Here's the entire output log from beginning to end.
Edit2: I don't know if this is significant, but if I paused execution (in Visual Studio), it always seem to be at Build/ProjectName/App.css => Line 78:
[MTAThread]
static void Main(string[] args)
{
var app = new App();
CoreApplication.Run(app); //<===== Here
}
You might want to check any of your Start() methods. You might have some code that is CPU intensive. Even if it runs smoothly in Unity, doesn't mean it will run easily on HoloLens since their CPU is not powerful.
Also, to avoid any Camera problems, make sur to use the Camera prefab from this
repository :
https://github.com/Microsoft/MixedRealityToolkit-Unity
Those are just some thoughts, hope it helps!
Turns out i didn't enable "Virtual Reality Supported" under Other settings in PlayerSettings. It's really dumb, but i hope this helps someone.
I've started a new React Native project and I keep getting the following warning:
Remote debugger is in a background tab which may cause apps to perform slowly. Fix this by foregrounding the tab (or opening it in a separate window).
It's a bit annoying so I wanna know how I can get rid of it? I'm running the debugger in Chrome and I moved it to a seperate window but it did not help.
If you have the Maintain Priority checkbox in the debugger window, try enabling it before you jump to any of the solutions below.
To get rid of the warning in your whole project add the following to your outermost Javascript file (most of the time that's index.js for React Native)
for react-native v0.63+:
Use LogBox:
https://reactnative.dev/docs/debugging#logbox
LogBox.ignoreLogs(['Remote debugger']);
for react-native v0.57 - v0.62:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
react-native v0.56 or below:
Add the following early on in your code:
console.ignoredYellowBox = ['Remote debugger'];
Easy, simple and specific to that error. Works for me. Can substitute for any text you want.
this solution is work for me
open/move http://localhost:8081/debugger-ui (default path for remote debugging) on the separate window
maybe that could help :)
You can use React Native Debugger available at https://github.com/jhen0409/react-native-debugger It is a standalone app for debugging React Native apps during development.
Move http://localhost:*****/debugger-ui on the separate window.
Restart Remote JS Debugging.
For me warning went away by checking Maintain Priority Checkbox!
It is because of number of tabs are opened in the browser with React Native Remote Debugger UI tab. I also faced the same issue.
To overcome this warning message you can use any one method from the following:
Open an incognito tab then paste http://localhost:8081/debugger-ui on address bar and press ENTER. Finally reload the app (Command+R).
Close all the tabs in the browser. Keep only 1 tab opened then hit http://locahost:8081/debugger-ui then reload the app (Command+R).
As mentioned by #jakeforaker in one of the comment. The warning went away by simply opening the remote debugger in a separate window instead of a tab in your existing window of your browser (you have to reload your simulator though).
As the warning is saying keeping the remote debugger in the same window as other tabs
may cause apps to perform slowly
So i think simply suppressing warning as mentioned by #kjonsson:- console.ignoredYellowBox = ['Remote debugger']; doesnt seem to be best solution.
Since this commit in March 2017, you can enable the Maintain Priority checkbox. When enabled, it silently plays a base64-encoded .wav file to prevent the debugger's browser tab from entering low-power mode, which can affect websocket performance. This will effectively prevent the warning you describe.
This issue was resolved when I closed all open Chrome windows and started the Remove Debugging again. I had previously had open Chrome windows, so it 'seems' that having them open kills performance.
I think the accepted answer is no longer accurate (at least for React Native v0.57+).
The correct code is now:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
I am on Macbook. I fixed this issue by bringing the Debugger window on main desktop, rather than on having it on separate desktop which it thinks is in "Background".
I had the same issue pop up yesterday. Googling it led to this Stack Overflow post. In one of the response (by adriansprod), he suggested:
Chrome debugger in it's own window fixes. But annoying problem
It is likely that your React Native debugger is not in its own Chrome browser window but in a Chrome browser tab. Pulling it out as its own window, as adriansprod suggest, fixed this for me.
The (very annoying) error message is handled by debuggerWorker.js, which sadly doesn't include any configuration options to turn off the message. So for the time being there are no ways you can configure your application to disable the message.
The related code is outlined below (original licence applies):
var visibilityState;
var showVisibilityWarning = (function() {
var hasWarned = false;
return function() {
// Wait until `YellowBox` gets initialized before displaying the warning.
if (hasWarned || console.warn.toString().includes('[native code]')) {
return;
}
hasWarned = true;
console.warn(
'Remote debugger is in a background tab which may cause apps to ' +
'perform slowly. Fix this by foregrounding the tab (or opening it in ' +
'a separate window).'
);
};
})();
As you see, no configuration options are used, the whole thing is scoped off locally (see the above repo link for further details).
I also have faced with same issue about one week ago and finally i have found solution that works excelent for me
It called reactotron, you can find it here - https://github.com/reactotron/reactotron and you can use it to:
* view your application state
* show API requests & responses
* perform quick performance benchmarks
* subscribe to parts of your application state
* display messages similar to console.log
* track global errors with source-mapped stack traces including saga stack traces!
* dispatch actions like a government-run mind control experiment
* hot swap your app's state
* track your sagas
I hope my post was helpful and you never will faced with this tedious warning .
Good luck
I use this in index.js
if (__DEV__) {
console.ignoredYellowBox = [
'Remote debugger',
'Warning: isMounted… is deprecated',
'Module RCTImageLoader'
];
}
I had minimised the "http://localhost:8081/debugger-ui/" window. Just opening it up (un minimising), and reloading the app removed the warning.
there might be chances that Another debugger is already connected to packager.
so close your terminal and debugger google chrome.
if you are using visual studio's package manger then don't start package manager by Mac/other os terminal command.
so close all terminal and stop on going package manger and google chrome debugger.
start the process again.
Similar to Akshay Vijay Jain, mine went away by ticking this box!
I am working on an app, where I display the data entered by user in a PDF file. PDF File is also created dynamically.
All this is fine.
I have implemented QuickLook framework to display the pdf file. When I call the QL framework, PDF file id displayed quite fine but when come back to the calling screen, my app crashes without any crash log or memory warnings.
I am calling QL with below code:
[[self navigationController] presentModalViewController:qlPreviewer animated:YES];
logs created are
DiskImageCache: Could not resolve the absolute path of the old directory.
[Switching to process 3070 thread 0x17603]
[Switching to process 3070 thread 0x15503]
This is quite interesting.....
When I run the same program in Instruments to check for leaks and Memory Management, i can only find leaks when PDF document is scrolled and all the pages are viewed.
However, interestingly there is no app crash that I can see.
Also, I did try with ZombieEnabled = YES and without it but no app crash with Instruments.
I am quite clueless on how to interpret this and have been trying different things to solve this. Also, I have tried UIWebView but the result is the same.
I was again trying something to check out the issue and found something interesting.
When i execute the code directly from X-Code - i get the crash in as explained above.
In other instance, if I execute the app by clicking on the app in the sim... no crash
I am yet to check this on device. Can someone confirm the crash on the device?
Also, Google does not have answer to this question.
Thanks in advance for your answers.
Can anyone shed some light on this?
I'm having the exact same issue.
As a workaround, you can disable or remove your 'All Exceptions' breakpoint. This might make debugging a little more difficult, but it's not as bad as having to relaunch the application all the time.
This is the breakpoint causing the issue. I had set it so long ago that I'd forgotten it was there
Deleting application from device helped me to solve this problem.
Maybe also at first you should try "Product > Clean" to ensure that all resources will be copied to your device.
I was able to fix mine with this code:
FirstViewController.h
NSURLRequest* reqObj;
#property(nonatomic, retain) NSURLRequest* reqObj;
FirstViewController.m
reqObj = [NSURLRequest requestWithUrl:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:60.0];
NSURLConnection* conn = [[NSURLConnection alloc] initWithRequest:reqObj delegate:self];
then instead of loading it on my view after this line i waited for the connectionDidFinishLoading then load it to my view
Interesting: This has just started with my app too. No errors when checking for leaks but running the app in the sim actually is causing a Breakpoint, not a crash. I can hit the continue and the app keeps running, no problem.
My issue also is relating to a PDF, but I'm just using a web view to display a PDF from the app bundle. I've checked everything in the dealloc, it's all good, this may be a iOS 5.1 bug. I will update as I learn more.
#JimP, It isn't an iOS 5.1 bug. It has just started happening to my app as well, on iOS5.0. It seems to only affect pdfs of more than one page length, and seems to trigger most commonly on scrolling past the end of the document (although sometimes earlier also). It also seems to happen more often on a second load.
This could happen when you delete the object reference in code but having its reference in xib. Delete the outlet that you no longer need.
Just ran into this problem of loading a pdf file in an App I am converting to iOS 8. This App has been running fine since the first iPhone. I just removed the All Exceptions breakpoint to work around it.
I don't know if it's the same problem but I had an issue where switching from a PDF view to another more than three times via the tab bar controller caused a crash.
Turned out that embedding the views I was switching to within Navigation controllers put a stop to the crashing.
Background
I'm using UKCrashReporter in my app.
I've installed my own Uncaught
Exception Handler.
I'm setting up the
managedObjectContext of the object
activeItemController in
applicationDidFinishLaunching (1)
The Problem
If the managedObjectContext method throws an exception, the crash reporter dialog box only flashes up before the app crashes and so the user never gets to report the crash.
I want my app to continue only after the crash has been reported, not whilst the window is showing.
What I've tried
If UKCrashReporterCheckForCrash()
were an objective C method, I assume
I could call
performSelectorOnMainThread:waitUntilDone:YES
but it's not.
I've looked at some other Stack
Overflow questions about using
Conditional Locks to pause apps,
but I can't understand how I'd use it
for a C function.
How would I go about doing this in a nice way? Do people have any advice
for me? Any responses would be much
appreciated.
The Code
// In app delegate
-(void)applicationWillFinishLaunching:(NSNotification *)aNotification {
UKCrashReporterCheckForCrash(); // A C function which then creates a window if
// it detects a crash has happened.
}
-(void)applicationDidFinishLaunching:(NSNotification *)aNotification {
[activeItemController setMoContextDisk:[self managedObjectContext]];
[activeItemController setMoContextMemory:[self managedObjectContextMemory]];
}
Update 1
I've been asked for more details on what I'm trying to do, so here goes.
The bug that triggered this thinking was an exception when merging managedObjectModels. My app got caught in a loop printing "Uncaught exception" to the console every few milliseconds.
And when I installed the uncaught exception handler before this exception happened, I'd get the described behaviour - my app would fire up, display the crash report dialog briefly, then continue to load and crash again.
Summary - I want to be able to handle errors that happen on startup.
(1) I'm not using bindings to do this, as I thought bindings would make testing the class more problematic.
I think your problem is with thinking of it as "pausing" your app. Think of it more as a different initial UI state. Your attempts to block the run loop will prevent any interactive window from ... well, being interactive. :-)
Your best bet is to show your main UI (and connect data sources, etc) only if the "am I prompting the user to submit a crash report" method says "no, go ahead and start normally". Otherwise, show your window and, when the user sends or declines to send the report, close the window and ask your app controller to continue the normal startup.
I looked at UKCrashReporterCheckForCrash() and it doesn't appear to create a window of any kind. It merely submits the crash. Could you describe what you're doing with more detail?
It is quite tricky because I wanna to take the result as a sign for later process. If a window flashes, it would be weird to user.
(This is not an answer, just refreshing the question and adding some details:)
Suppose you need to open a video capture driver (webcam) with code like this (delphi, but easy understandable):
result:= SendMessage(hCapWnd, WM_CAP_DRIVER_CONNECT, FDriverNo, 0);
It works fine, except when camera/webcam is busy (opened by another application, for example moviemaker). Then the capture driver suddenly shows a "select video source" window that blocks your application (but not moviemaker, which keeps recording). SendMessage function becomes modal and will not return until undesired window is closed.
Is there a way to detect if a capture driver is busy with another application before connecting to it?
Thanks
This function return number of available webcams and scanners on your mashine(с++).
int GetNumCam()
{
int MemberIndex = 0;
HDEVINFO dev;
SP_DEVINFO_DATA DeviceInfoData;
DeviceInfoData.cbSize = sizeof(DeviceInfoData);
dev = SetupDiGetClassDevsA(&GUID_DEVINTERFACE_IMAGE, NULL,NULL,DIGCF_PRESENT);
if (dev == NULL)
{
MessageBoxA(0,"it is null..","vse propalo",0);
return -1;
}
else
{
while(SetupDiEnumDeviceInfo(dev,MemberIndex, &DeviceInfoData))
{
MemberIndex++;
}
}
return MemberIndex;
}
I wonder if sending a broadcast message could do. I mean, suppose you send a VFW info request message to all windows in system. Then, all windows actually doing VFW processing will answer their status info and you will know which of them are doing video processing; some kind of shouting "anybody here...?"
But it looks like brute force, or even hacking. May be I'll test it... may be not. I am sure there must be a smarter way to know if a video capture driver is busy with another application.
(btw... anybody here?)
I was afraid it would happen.
First I enumerated all opened windows in system, then executed this instruction for each HWND, which just asks for driver information (pascal syntax):
SendMessage(h, WM_CAP_DRIVER_GET_NAME, length(driver)*sizeof(char), LPARAM(PChar(driver))
According to Msdn help, WM_CAP_DRIVER_GET_NAME results are:
"Returns TRUE if successful or FALSE if the capture window is not connected to a capture driver"
(Bold is mine). So it appears a good way to know:
1-If the window is capturing. So it is applyable to ALL windows, don't matter if they are capturing or not.
2-And if so, it tells you which driver is using.
However, after first test round, the results were:
- Task Manager (it was running) crashed and closed
- Explorer crashed and closed (reopened again automatically)
- Belkin Wireless monitor (my pc's WiFi driver) crashed and closed
- Eset Nod32 antivirus crashed, did not closed
The first conclussion can be that this is a bad way to locate which applications are capturing video in a system. But I must ensure to dismiss the possibility of a bug.
I'll keep reporting.
This is not a good solution my any means but I found out that if you disable and enable the camera in device manager immediately before sending the WM_CAP_DRIVER_CONNECT message then for some reason the video source window does not appear and the function returns and works OK.
So for a script I was working on I had to download devcon.exe and I put "devcon disable *PID_3450*MI_00*" and "devcon enable *PID_3450*MI_00*" immediately before my WM_CAP_DRIVER_CONNECT and it seems to work consistently. Unfortunately you need to run as administrator to be able to disable/enable devices. Again not a proper fix by any means...
(Hardware ID of my cam is USB\VID_0AC8&PID_3450&MI_00)