The window.applicationCache status is 2(Checking) when the issue occurs. I have some method called on the listener to some of the application cache change events. But when the issue occurs, I see none of the events getting fired.
Request to Manifest is also stuck forever when I inspect the network tab.
The device I am using is Ipad IOS-12.0.
In the success scenario, the status is 2(checking), then it raises noupdate event and subsequently the application cache status changes to 1(idle). This issue is intermittent and gets reproduced sometimes when I freshly launch the web app.
Since this feature is going to be deprecated by apple, the support hasn't come. you can do a workaround instead, have a listener on the checking event and may be after a setTimeout of 3-4 seconds you can perform your further calls.
Will keep this thread posted once an update comes.
Related
My app creates a window with a local page that requires node integration to be enabled.
After I click a button on this page, I am navigated to a third party page.
Because I want node to be disabled in this third party page, and I can't toggle node integration in a BrowserWindow, I load this third party page in a sandboxed BrowserView that is embedded inside of the window and is stretched to fit the entire screen.
Now doing this navigates the embedded view, but the BrowserWindow is stuck pointing to the old local page that is no longer relevant.
To prevent this extra page from sitting around in the background, I navigate my BrowserWindow to "about:blank" to effectively clear it out and make room for the BrowserView.
I am realizing now that while this "clears" out the old page, it keeps the renderer process that's associated with it alive. From here:
Chromium creates a renderer process for each instance of a site the user visits
And understandably, navigating to "about:blank" doesn't signal to Electron that it should kill the other process.
I want to get rid of this renderer process, so it doesn't sit around unnecessarily and use CPU and memory when I interact with the window.
Two things that have worked:
I removed the extra navigation to "about:blank" since we're now killing the process and:
1) When my button in my renderer sends a message to the main process telling it to create a BrowserView and navigate to the new site, I do a process.exit();. I guess a part of me is nervous about the process exit interfering with the message that gets queued up for main, though it seems to work fine.
2) Instead of killing the process from the renderer, I created and navigated my BrowserView and then ran a little browserWindow.webContents.executeJavascript("process.exit()");. I find this uglier, though it does mitigate by concern above in #1.
There isn't a webcontents.destroy() type of method, and I don't know of a way to signal to Electron that it needs to destroy this unnecessary process.
I suppose I might have a pretty unique case, but is there a nicer way (or more standard way) of handling this than explicitly doing a process.exit()?
There is now a WebContents::forcefullyCrashRenderer() API that accomplishes this (introduced by this PR):
Forcefully terminates the renderer process that is currently hosting this webContents. This will cause the render-process-gone event to be emitted with the reason=killed || reason=crashed. Please note that some webContents share renderer processes and therefore calling this method may also crash the host process for other webContents as well.
As of now (July 2021, Electron v13) - there's also an undocumented webContents.destroy().
https://github.com/electron/electron/issues/10096
As the documentation mentions, some webContents share renderer processes and if you use webContents.forcefullyCrashRenderer() you may terminate them as well.
I'm not sure about how webContents.destroy() handles it, but from the name it seems to be more narrow in scope. I would assume that it kills the renderer if webContents is the only webContents attached to it (I tested this) and spares the renderer if other webContents is using it (needs confirmation).
I'm creating mobile app based on Twilio and Cordova (https://github.com/jefflinwood/twilio_client_phonegap), it works well, but I seem to have a problem with connection events.
The problem is ConnectionDelegate callback connectionDidDisconnect doesnt seem to be fired in some situations. For example:
User 1 is calling from browser
User 2 anwsers on iPhone/Android/Browser
They talk
User 1 hangs up in browser
User 2 will get disconnection event on every other device than iPhone. On iPhone callback connectionDidDisconnect is not called at all.
Another situation:
User 1 is calling from browser
User 2 anwsers on iPhone/Android/Browser
They talk
User 2 hangs up
User 2 will get disconnection event on every other device than iPhone. On iPhone callback connectionDidDisconnect is not called at all.
Could you tell me where I'm making mistake?
UPDATE:
When user anwsered incoming call on iPhone and caller hangs up I get [ERROR TCMetricsPublisher] Failed to push call stats, status code: 403 error.
When user anwsered incoming call on iPhone and he hangs up, nothing happends.
From others experience using the same plugin, it seems you can solve the issue by using the status callback that Twilio handles when the call ends. Modify the call from parameters and set the status to "completed" for this call.
Doing this should allow the call to disconnect properly on iOS.
Please let me know if this helps at all.
The MediaElement.js library for HTML5 video is the most complete option that I have found, and also the only one I can use on this project.
The problem is that when the videos load poorly over a slow connection, neither the video element or the MediaElement library dispatch an event when the video stops playing and begins to buffer. This is only happening in Chrome and Firefox.
I have added event listeners to the stalled, waiting, and suspended events, and none of them are fired when the video pauses to buffer in Chrome or Firefox.
Any ideas? Any help is greatly appreciated.
Thanks!
If you look at the code for MediaElement.js, you'll notice the stalled and suspended are not set for MediaElement object. Waiting wouldn't work because it's called when the playback is waiting on another operation (e.g. seek)
waiting: Sent when the requested operation (such as playback) is delayed pending the completion of another operation (such as a seek). https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Media_events
This is not tested, but you can try the following
Set a playing event that will create an interval to check the current
time of the video. If the video current time didn't change from last interval, than
most likely the video is buffering or not loading.
Set a pause event to clear the interval.
You might need to set other events to make sure the event
is not triggered by user actions.
Hope this helps.
I have an (old) audio app that is misbehaving on iOS 5.1.1. It records audio and on older iOS versions (don't know precisely where the "break" is) it would stay "in foreground" while recording, without any nudging.
But on 5.1.1 the app is put into background after two minutes, and then things go sour. Currently (will have to change this, I suppose) the app kills recording when it's backgrounded (and it appears to do this successfully), but it still dies with a trap in the above routine.
Unfortunately, the call stack is empty when this occurs, so there's little clue as to why the app's getting killed, but I gather (just from hints here and there on the web) that the trap occurs because a background app cannot use any UI facilities, and the app must somehow be calling something UI-ish. But I haven't a clue what it might be.
I've worked through most of the notifications, to see if a notification might be lurking in a queue somewhere and doing something, but I've not found anything so far that might be triggering a UI opp.
Any ideas on how to track this down?
Aha!! The app uses an Apple freebee widget known as AQLevelMeter. When recording is stopped, the level meter is also stopped, but the stop code inside AQLevelMeter.mm does not invalidate the timer that's driving the UI updates.
While launching the application in my iPhone, I need to download the data from the server. While downloading data(in middle of process) if I press home button to enter the application into background.this time I need to stop the API request which is already executing. currently applicationDidEnterBackground method is calling with delay(after downloading data). In the mean time application is crashing. how can we cancel the URL connection while application is entering to background.
Please help me out.
Thanks in advance.
One way to do it is to set some kind of flag in your app controller that you can periodically check to see if the request is cancelled.
Or, even better, the NSThread object provides a mechanism to indicate that it should be cancelled. If you go into the background, set your detached thread to cancel (via [NSThread cancel]) and then in whatever API callsback you have, you should periodically check to see if [NSThread isCancelled] is returning YES.
Here's a link to Apple's documentation on [NSThread cancel].
http://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Classes/NSThread_Class/Reference/Reference.html#//apple_ref/occ/instm/NSThread/cancel
hope this helps!