I have a cocoa application where each document is basically a webview. It works very nicely, but I noticed that when I have a javascript routine running, the interface locks up. I downloaded the tutorial code from the apple docs, and in there, it works fine ! The only major difference I can still spot, is that the tutorial uses a single window and is not document-based.
so I am assuming that this is the culprit. However, I am totally lost in how to solve this
i've uploaded a screenshot here : (removed because i don't have 10 rep yet so i can only post one link) and you can see that I have two xib files : one for the app and one for the doc...
can anyone hint me how to handle this ?
EDIT : after crunching my brain for a whole night, i came to the conclusion that even on single window it doesn't work... I managed to make a very small test experiment here : http://noglangengelukkig.be/ex.zip
opening, compiling and running it will work fine, but as long as the network is stabilizing (= the nodes are still finding position), you can't click.
the page that it is showing is this one : http://www.beergraph.xyz so you can see that it works perfectly in safari !
i found it... i'm an idiot... the reason things locked up was NOT webkit : it was the fact that the javascript code could not figure out which browser was running it, and thus assumed that setTimeOut() didn't exist and fell back to blocked-timing
Related
I'm using opengl es 3.0 API with the android studio ndk to create apps.
But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.
This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:
eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;
I've error checked that eglDestroySurface() is successful.
And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.
UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?
UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.
Is it the "Strict Mode" developer option on the device settings, perhaps?
That one flashes the screen if an app is blocking.
It would explain why a factory reset changes behaviour.
The answer is not a solution here. The above comment by the user columbo was correct.
I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.
I've been trying to use batch testing to test my luis app and have been experiencing an annoying bug. Basically the LUIS app page will become unresponsive while the batch testing window is open.
The most similar issue I've seen can be found here: LUIS web interface crashed after import JSON file for Batch Testing or Import App, with no answer yet.
My problem is also slightly different by the looks of it.
Experimenting has yielded the following results:
I can upload, test and view the results of 1 batch successfully sometimes. Sometimes the page will become unresponsive while I am looking at the results.
If I have successfully viewed the batch, but then close the batch testing window without deleting the batch, the next time I open the window the whole site will become unresponsive.
Recently opening the "Inspect" tab on the single utterance testing window has also begun making the page unresponsive.
I can submit images if needed, but the pages seem more or less the same after the bug has occurred, they simply stop working. Pressing buttons does nothing and I need to refresh the page if I want to get back to the bot's Dashboard/Build/Publish/Settings page.
The app has 18 intents, 12 entities, and a couple hundred utterances. I have tested it on a collaborator account and the bugs seems to occur there too. Not sure what other info might be relevant.
If anyone has experienced similar issues and can help I'd appreciate it. Being able to use the built in Batch Testing feature would be very useful.
I have a Mac desktop application developed using Xamarin.Mac and XCode. The application is loading views that should have a considerable amount of content as blank/white screens for a select few end users. While I've not been able to reproduce the issue locally and it doesn't appear to be impacting many people, it does happen consistently for a handful of users(6 out of over 4,000 at the moment). The app works just fine for the vast majority and uses a main window controller that sets the content view as needed by calling the applicable ViewController. When the views in question are loaded for the given users, it renders as a blank white area.
I did notice however that at least some of the objects in the views are actually there, just not visible. For instance, one view has buttons that are still "there" as you can click on them if you know where they are supposed to be positioned(and they also fire correctly) but they are not actually visible as the area is all white with no visible content. It's as if everything is loading properly but the UI just isn't cooperating in displaying objects that are actually there. The closest thing I could find was this Diagnosing run loop issue (partially frozen UI) in Cocoa application
However I'm not sure it's the same problem and there was no resolution for that either. Has anyone else ever encountered something like this?
Ok, got some new info. After doing a remote session with a user we had no luck with the hardware and the console didn't provide much insight, however we did stumble across a workaround that fixes the issue and may give some clues as to the real problem.
When the application is initially installed, we prompt the user to ask if they want it moved to the default Applications directory. They do not have to move it as it will work the same from pretty much anywhere but we do this for convenience. For the users having this problem, we noticed that they all had the app installed in the Applications folder. By sheer luck, one user accidentally chose to not move the app after reinstalling it per our support team. When the app was installed in his default Downloads directory, the problem vanished and the app worked as expected.
After testing various other directory locations(Downloads, Documents, etc.) we found that the issue only seemed to exist if the app was installed in the Applications directory. Furthermore, if the app was installed in the Applications directory, we could simply move it or copy/paste it to another directory outside Applications and when launching it from that new location the issue was resolved.
Seems like there is something specific to the default Applications directory that is causing this to happen(as odd as that sounds). Keep in mind that even when the app is installed in the Applications directory, this issue only happens to 7 people out of over 4,000.
Any ideas as to what might be special about that directory that could explain what we're seeing?
There has been very little changed to this page since it just recently stopped loading properly on Chrome.
If you click the link three times things usually load up fine. I've looked through the developer tools and can see that it's hanging up on the js the first load. The second load has pending on most/all of the .jpgs, and then finally another click/load works.
I know it's a heavy site, but the other pages are fine, in terms of actually loading and not just going idle, and this loads well enough in Firefox. I don't think this site is even the largest of the pages in terms of images and video.
I've gone through others solutions to this problem by changing the "https" and renaming files incase an adblocker was causing it, but nothing seems to work.
Any idea of what in the page is causing the issue?
I have a code, which captures a given window by PrintWindow function. Specifically I do capture web-pages in a browser. This code is tested in a standalone Windows application, and it works ok. The same code is incorporated into NPAPI plugin and loaded into Google Chrome. There problems happen. If Chrome has only one tab, the code works OK. If Chrome has 2 tabs, the code returns black box of expected size. I tested the standalone application and the plugin at the same moment, on the same window handle (Chrome_RenderWidgetHostHWND). Application does ALWAYS work, the plugin does ALWAYS fail if multiple tabs are open in the browser.
I'd really appreciate, if someone give a clue how to fix this.
Thanks in advance.
NB. Other methods of capturing windows are inapplicable due to even greater shortcomings for my usecase.
I bet you're running into sandboxing issues.
Your app is likely running at the "normal" integrity level, so it has no problem posting the WM_PRINT or WM_PRINTCLIENT message to the Chrome process. (PrintWindow uses these messages under the covers.)
When you're a plugin in Chrome, I believe your code runs as a "low" integrity process (which reduces the chances of things like shatter attacks). Thus it doesn't surprise me that sending the message to a window in another process fails.
Unfortunately, that doesn't explain why it works when Chrome has only one tab. Are you finding the same instance of Chrome_RenderWidgetHostHWND in both the app and the plugin in the case where you have multiple tabs open? In general, there's one of these windows per tab. How are you finding the window?