I'm working on an NPAPI based plugin, and have been observing an issue when opening the context menu in Chrome, displaying an error message saying that the page is unresponsive after leaving it open for 30 seconds.
I've observed the same issue with Flash Player 10.3 (which uses NPAPI, 11.x versions uses PPAPI).
Also, this issue only happens with Chrome, and trying to open the context menu when we aren't in the mouse down event takes no action, and no menu gets visible.
Any thoughts?
Thanks,
Rodrigo.
This is simply a bug in Chrome's NPAPI plugin host on OS X.
The reason why this happens is that you must not ever block the main thread, and when you have the menu open you're blocking the main thread. Since the main thread is blocked, the plugin doesnt' communicate back to the browser process and the browser process detects it as being frozen.
The only solution I can imagine would be something that lets you do what you need on an alternate thread. Chrome will always display that notice if you block the main thread, no matter what you do.
Related
I have an Electron app, running on Windows, it has a few controls on the main window and a cancel button. I notice when it is running I see two threads, I assume the main and renderer threads. When the cancel button is clicked the renderer sends an IPC message to the main thread and the main thread calls app.quit. Under these conditions the two threads end. If I right click on the icon in the Windows taskbar for the app and select "Close" the threads only end when the app is run under the VSCode debugger, when the app is run without the debugger and the same is done the two threads remain.
How can I debug this? Any suggestions as to why it is happening.
Under the debugger I see the close being caught in the main thread and app.quit is called.
UPDATE: Since the app used Electron 1.7.9 I have updated it to use 2.0.8 just in case this was an issue that had been addressed. However, with 2.0.8 the issue remains.
Sid
Thanks to some input from the Electron Slack community I have resolved this issue. My mistake was in the way I was calling the app.quit() method.
My code was handling the MainWindow on "close" event and executing the app.quit() method in that event handler.
The correct way to close the app is to handle the app "window-all-closed" event and execute the app.quit() method there.
Here is a gist of a skeleton main.js for an Electron app that was sent to me to help me resolve the issue.
https://gist.github.com/sidprice/612cb49cec923eeb94cfcddf1736c181
Sid
I have a simple set of HTML and JS which when I test it directly as a web page, loaded locally from the file system in Chrome, works fine. I can click a button causing a call to navigator.bluetooth.requestDevice. This correctly causes the usual window to appear and it lists the expected Bluetooth peripheral. I can then select it and successfully pair, with my code receiving the expected callback.
If I try to execute the same html/js as a Chrome app, with a manifest and invoked from chrome://extensions the requestDevice window appears and lists the expected peripheral with the Pair button disabled. If I select the peripheral, the Pair button becomes enabled but if I click it, the window disappears into the background, behind Chrome and nothing else happens that I can see. My code receives no callback. It looks like the call was competely ignored.
What do I need to do to make this work within a Chrome app?
Thanks
Chrome Apps and Extensions should be able to use Web Bluetooth. This is a bug. I've filed chromium issue 751819.
As a work around, create the Chrome App window larger than the device chooser dialog that pops up.
Note: this is not a newbie question
Main window of my application occasionally "freezes" with symptoms listed below. The application continues to work properly as soon as main window resized.
Debuggers, Windows Application Verifier and other tools I used revealed no problems.
What could be a reason or how can I check why the window becomes blocked from updates?
Some details:
old 32-bits c++ MFC application, worked fine for many years on many Window XP installations in 24/7 mode
the app renders some simple 2D graphics with MFC/GDI functions
on several computers under 64-bits Windows 7, very rarely (~once per month) app's main window stops updating: it looks exactly as if the app took a screenshot of client area of its main window and shows this screenshot until mail window resized
my diagnostic logs and all kind tools indicate that once frozen, internally the app works normally: it still renders updates but because of some reason Windows ignores them
application main menu opens and works properly
all drawings are made in single thread
various modal dialogs called via main menu also work properly
Notepad brought on top on my app shows properly and leaves no traces behind
Windows itself and all other application always work properly
I would think this is something related to the video card/its driver we are using (3 monitors connected to two NVIDIA NVS 300) but I don't understand why only my application is affected. Also I would love to know with what magic the resizing removes the update lock.
Update 12/9/2015:
I'm sure the drawing thread is not blocked: it is application main thread that also always properly responds to mouse clicks, menu commands and keyboard
All counters (memory, processor, GDI/USER objects) indicate no problems
I'm currently trying to build and run an UnrealEngine4 demo app, which uses SDL2, on a Linux armv7 embedded system with X server running but no window manager.
What I'm seeing is that the app is not responsive to keyboard events, although mouse works fine.
Digging further it turns out the problem is that UE4 ignores the keyboard event if the SDL_Event.key.windowID does not match the ID of the app's SDL_Window. I verified this by calling SDL_GetKeyboardFocus() and it turns out the window ID for the keyboard focus is 0 whereas the app's window's ID is 5.
Digging a bit further inside SDL2 it looks like the keyboard focus is set to a particular SDL window after a focusIn event is received from the X server. (see X11_DispatchEvent() in SDL_x11events.c).
It looks like if you're running X11 without a window manager however this focusIn event is never generated by the X-server as already answered here:
FocusIn/FocusOut not generated
After hacking X11_RaiseWindow() in SDL_x11windows.c by adding:
X11_XSetInputFocus(display, data->xwindow, RevertToParent, CurrentTime);
SDL_SetKeyboardFocus(data->window);
was able to finally get the keyboard events processed.
Does the above assessment sound correct ? If so is there a clean solution to this ? I'm still digging around but any suggestion would be greatly appreciated.
Thanks
This turned out to be a bug in SDL, which we just pushed a fix for:
https://hg.libsdl.org/SDL/rev/aa4e4768c6c1
This fix will be in SDL 2.0.4, and should bubble over to Unreal shortly thereafter.
I am facing some issues in WP7 tombstoning. My issue is application hangs when i try for a sudden tombstone and come back. ie, After loading the page i press device menu button and with in seconds i pressed back button( Pressed Back button before the actual page disappeared) In that time the page loads but the application hangs / its back key press is not working. and if we try for a slow thombstone it is working perfectly. And the pretty interesting thing is that, while tombstoning the loaded and unloaded events of APP working perfectly. Please any one help me to solve this issue.
It sounds like your App has been deactivated, but not tombstoned. This results in neither the App or Page contrusctor being called, causing your app to act in unexpected ways. I highly recommend reading the Windows Phone Silverlight Application Life Cycle document. The relevant extract for said article:
This case can occur if the user
presses the Start and Back buttons on
the phone in quick succession. In this
case, the application received a
Deactivate event and the system was
starting to save the state of the
application to perform an application
tombstone. Before this operation is
completed, the app Activated event is
received. The system knows that the
application was not removed from
memory, so the flow of execution is
different. Specifically:
• The app constructor is not called.
• The page constructor is not called.
The only way for the application to determine
if this condition has occurred is to
set a flag to indicate if the page
constructor has been called. If you
notice in the above section, this flag
was set in the page constructor, and
cleared in the OnNavigateFrom event.
In this case, we will receive the
OnNavigatedTo event, but we will see
that the page constructor was not
called. This tells us that our
application was not tombstoned.