I have a console app which monitors assorted things 24/7 and will issue warnings if it detects any faults. The other day I noticed that it failed to warn me about something and I later worked out that I accidentally clicked on the app thereby highlighting a single text cell in the console and the app was then locked up waiting for me to perhaps "copy" the highlighted text. This is rather hard to spot and I am concerned that it could happen again. Is there a way to prevent such locking - perhaps disabling any clipboard operations altogether?
Related
When developing my react app the app becomes unusably slow with the devtools open in chrome. Works fast and fine with them closed or in incognito mode. I have tried disabling all extensions and had the same problem. This seems to have started happening recently when I updated chrome (now on Version 80.0.3987.132).
I am not really sure where to start debugging this issue but it has become very frustrating to develop on my app.
Any advice or help debugging would be appreciated.
TL;DR: Go to the Sources tab and delete all breakpoints for the site.
I had a similar problem. My site was very slow to load, but only in specific circumstances:
Dev-tools were open.
Tab was in a normal window. (not incognito mode)
Profiling was not enabled.
If (and only if) all three of those conditions were met, the site would load unbearably slowly (15+ seconds; normally ~3s), plus have performance issues for certain operations on the site (like changing which subpanel was open). It was very strange.
Like you, I tried disabling all of my extensions, yet the problem persisted.
Attempt 1: I tried clearing all of the site's cookies and local-storage, using the info/lock dropdown at the left of the address-bar. Suprisingly, that seems to have fixed it! (edit: this was not the root problem; see below for that)
So the problem must be that my site was storing too much data in local storage or something, such that dev-tools was choking on it (but only in specific cases, for some reason). This also matches with the issue resolving in incognito mode: incognito mode uses a "clear slate" for site cookies/local-storage.
Anyway, it's an odd one, but the cookies/local-storage clearing seems to have worked for my case. (If the issue comes up again, and the solution above doesn't fix it, I'll try to remember to mention it.)
Update: Oddly, having the profiler on still speeds things up even after the fix (ie. those three conditions being met still slows down page loading and actions, just much less than before the fix). So apparently the fix merely "reduces the intensity" of the problem rather than fully fixing it; like, by resetting local-storage, it lessens the size of that data, which somehow is a variable affecting the core problem (not yet identified).
Attempt 2: I believe I have found the root problem and solution: I removed all breakpoints for the site, and the slowdown was solved completely. So the problem seems to be that I had lots of unneeded breakpoints set at various places in my website code (some enabled, some disabled). Some of these must have been placed in/near "hotspots" that were getting called frequently. By having the dev-tools open, the Javascript engine must have had to start performing some processing related to the breakpoints, slowing things down.
My guess is that the problem would also be fixed by disabling the "JavaScript source maps" settings (as that's the only thing I can think would cause so much slowdown), but I haven't confirmed this.
This has most probably something to do with this commit, titled "Stop sending profile data when recording is off".
They already know there is an issue with the Developer Tools slowing down and they tried to prevent it by preventing profiling data to be sent via the bridge to the frontend, when not recording.
As reported, it seems the issue is not happening anymore, on the latest version. However, the cause is still unknown.
Try uninstalling the Developer Tools extension, clearing browser cache and then installing it again.
You should probably try using a version other than the one you're using, Version 80.0.3987.132. The app you are trying to develop might not be suitable to the version you are using. Delete the extension you are using, clear and remove every trace of browser cache and then re-download the extension, like what Daniele Molinari said. It might help. If it doesn't let me know. I'll try a different approach.
I'm inspecting a performance issue with an AngularJS application.
When performing specific actions, the CPU usage goes to 100%, the Chrome window freezes, and I have to manually terminate the process using Chrome's task manager.
I tried to debug the app (DevTools' Sources tab), but the application is quite large and the code is minified, which means that finding the issue won't be easy: I see a lot of code triggered by the digest cycle, and can't figure out which code is the actual culprit.
What could be helpful is to be able to profile the application once it freezes; I'm pretty sure the profiler will immediately show the actual bottleneck. I can successfully start the profiler (Performance tab) before the freeze happens, but once the application freezes, when I click on Stop button, the Loading profile window is stuck at zero percent (I waited for fifteen minutes just to be sure, it's still at zero), so I suppose that it's frozen as well.
Therefore my question is:
How do I find what causes the application to freeze when I'm unable to figure it out by simply debugging the application?
To answer my own question, the solution was to use a different browser. Surprisingly, Firefox let me profile the application during the freeze. The remaining part was easy, as I expected: by comparing the profiling results before the freeze with the ones after it, one could figure which code is executed repeatedly.
Thanks to Aleksey Solovey as well for his comment.
I'm working on an app using geo fences but I'm hitting some issues.
I've been testing on Android predominantly so far.
a) I set up the geo-fence and it triggers fine for enters and exit events.
However, after an extended period time (such as a few hours or overnight) the events stop until the app is opened again.
b) My other issue is the geo-fence exit seems to trigger even when I haven't moved at all, and definitely not outside of the radius (150 meters).
I've looked at https://www.codenameone.com/javadoc/com/codename1/location/Geofence.html, and my code is very similar to the example.
Are there any other build hints I need to make it more accurate and persist in the background?
Geofencing should only be added once, it's a very flaky API in the native OS especially when it comes to background behavior that breaks frequently with OS updates.
Use something like:
if(Preferences.get("AddedGeofence", false)) {
addGeofenceBinding();
Preferences.set("AddedGeofence", true);
}
And see if this works.
I'm working on an rather small application (C#, winform) that is kind of front-end to MS Access database file stored on shared drive. While it is possible that drive could be down I am checking connection while loading Main Form.
I would like to know your opinions on how to deal with this problem.
I came up with ideas like:
Application shows only MessageBox
with an error message and close
itself (before actually showing up),
as it won't be useful at all.
Application load itself and then
display an error-message to not make
users confused (if they click warning
before reading the explanation).
What are yours best practices?
I think it's rather irrelevant whether the application is shown or not because in the end, you display the message box with the error anyway. The user clicks OK and you close your Application.
However, to me it's a bit nicer without the application showing in background, mainly because it makes no sense to fire it up when the database isn't available. Save yourself (and the pc) the time it takes to show it ;)
I have a WPF application that is doing some serious work (doing some calculations) when a button is hit. I wanted to add a 'busy animation'. However, the application is so busy doing its work that the animation is stopped until the calculations are finished.
The serious work should always be handled in a separate thread otherwise the complete user interface may be blocked. So you are unable to click anything and not even close the application.
If it is possible you should also try the make small chunks of work and give the rest of the application time to "take a breath" and not do all work at once. It's not always possible but some work can be managed that way.
Are you running your "serious work" in the UI thread? If so, you need to move the work to a separate thread if you still want the UI to be updated.