while using dev tool record and play for testing a website when a new window is opened or a new url is loaded then a time out issue occurs in the replay mode. How we can fix this issue and replay the recorded actions completely without errors
I tried to wait the replay action to load the site and return the result
Related
I've got case when user wants to login and from time to time, the login page freezes (page is loading all the time) and nothing happens. The problem disappears when user open the app in “Incognito” mode in Chrome. I observed the same situation happening sometimes in Incognito mode too however, when performing some internally tests. The only way to solve this situation when it happens is to clear all caches and delete all web browsing history. I've got this response from the server https://monosnap.com/file/jmEkKWaGelHYzTODq385choJ8pke3J
I thought it the problem could be in some docker images (some container/image overrider) but I've only one container so this is not the case.
Is it possible to set automatic data cleansing in Rails app that the user does not do this? I'm using Rails and Grape in this app.
My problem
I'm working on a project where Cordova is being used to display a remote website within the app. Cordova.js is being run from the remote server, etc., and this works pretty well.
I do have one issue though, especially on iOS devices.
If the device lose connection at the same time as I press a link on the website, the page will turn blank, as if to load the next page - but since the connection is lost nothing will be loaded into this blank page. Given iOS devices lack of back-buttons or such there's no way to navigate from this blank page except by closing the app and re-opening it.
My attempted, and failed, sollution
So, given that I can use Cordova.js to check for connection issues, I figured that I could use an iframe to display the remote website. If the connection goes bye-bye I'd just display a simple error message inside the iframe.
And well, this does work.
BUT. And this is a big but. InAppBrowser will not run from an iframe. And I can't live without the InAppBrowser, since it's used to display quite a few important features within the app.
So
Does anyone know a way to either:
a) Handle connection issues when running only remote content in the Cordova app?
b) Run the InAppBrowser from within an iframe? (I suppose I could use PostMessage etc. between the frames, but since I'm already sending/receiving data from the InAppBrowser I would love to avoid this in order to limit complexity).
c) Solve this issue in another fancy manner?
We have built an in-house Enterprise iPad2+ application that connects to a Drupal CMS, where content (text/images/video) is being delivered to the app via a REST API.
When the user launches the app for the first time, they are prompted to download the content over WIFI network. We are experiencing content failing to download inconsistently i.e. sometimes 60 images fail to download; other times 20 images fail. Since we've added video into the download mix, the content is failing even more often.
Server details:
Windows server
IIS7.5
PHP 5.3
MYSQL5.1
App details:
Require.js: provides JavaScript file and module loading
Backbone.js: provides a frontend JavaScript application framework
Cordova (v2.7.0): Used to provide an environment to run on iOS
Raphael.js: For procedural graphics and animations
jQuery and plugins: For Dom manipulation, animations and interactions
Bootstrap: Base framework for HTML mark-up
Download process is as follows:
User launches app and is prompted to download content
Download begins
The app now makes AJAX call to REST API to fetch content
Upon a successful fetch, the REST API delivers an array of content (text/images/video) - max video filesize 11mb
Content is delivered synchronously
We can add logic to keep retrying upon failure, but this could result in an indefinite loop. The content download size is approx. 50mb, over WIFI.
Our testing:
We have tried from 3 different locations in the world: SA, UK and US and similar issues.
We've tested a 300mb download from the same server, on the same iPad and it downloads fine
QUESTION:
Can anyone tell us why this would be failing?
Could the problem be with a Drupal configuration issue we're missing?
UPDATE 25 August:
We have done some more research and it seems the problem may be a result of iOS Safari timing out at 60secs, and then everything fails after that that to download - see here: http://www.sencha.com/forum/showthread.php?111231-iOS-Safari-Mobile-AJAX-timeout
Has anyone else come across this issue?
We have tried downloading over LAN, and that is 100% fine. WIFI is the issue.
We have tried refreshing the download script after x seconds and resetting the timeout counter. We've tried to detect if a download has failed and to continue retrying it.
Stumped at this point...
UPDATED SOLUTION 28 August:
UPDATED SOLUTION: we have fixed the problem. The issue fundamentally lies in the fact that iOS Safari times out at 60secs. Why? We have no idea... What we were doing was fetching the full list files to download, and then downloading them synchronously. What happened at 60secs, is the download times out and we were losing our file list. What we did to resolve this, is we saved the files not downloaded list at 60secs, then started the download process again with this new list, and repeated this process until all files successfully downloaded.
I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue
I'm having a problem with CocoaLibSpotify when trying to save my playlists for offline use.
So I install my app, log in for the first time, select a playlist and set it for offline use, immediately its offlineStatus changes to SP_PLAYLIST_OFFLINE_STATUS_DOWNLOADING, all the tracks in the playlist have their offlineStatus changed to SP_TRACK_OFFLINE_WAITING, they start downloading one at a time and eventually their offlineStatus changes to SP_TRACK_OFFLINE_DONE.
I turn off my wifi and I can play the downloaded tracks offline.
When I close the app and log in again, the tracks that were previously available offline now have their offlineStatus changed to SP_TRACK_OFFLINE_WAITING and can no longer be played offline. CocoaLibSpotify stores the downloaded playlists in the NSCachesDirectory, if I check that folder I see that the content hasn't changed and the track data is still there.
Another strange thing, I assume that, even in online mode, CocoaLibSpotify will play the downloaded track from the device if it's available offline. If I turn on wifi and I start playing on of these previously downloaded SP_TRACK_OFFLINE_WAITING tracks, then quickly turn off wifi, it still continues to play the entire track.
So from the looks of it, I'm assuming the tracks still remain offline but for some reason their offlineStatus gets the wrong status when logging in. And that the session refuses to start playing the track because of its offlineStatus.
But how can I avoid the tracks having their offlineStatus reset or at the very least, correct the problem when I know the track has been downloaded. I've tried setting the offlineStatus to SP_TRACK_OFFLINE_DONE manually but that didn't work. I'm hoping someone can shed some light on this.
Thanks in advance.
Manually setting the property won't affect anything but your UI.
There's a couple of things to check:
When you quit your application, make sure you logout ([SPSession -logOut]) and wait until the logout completes before letting the application die, otherwise you might get a broken cache.
When you log back in again, are you using CocoaLibSpotify's saved credentials or manually entering your password again? If it's the latter, it won't work since the library can't contact the Spotify service to verify the credentials. Using CocoaLibSpotify's built-in credential saving doesn't have this problem.