Closed
Description
steps to replicate:
- create two blank cordova projects with different bundle ids etc
- just put blank HTML pages saying "app1" and "app2" as the HTML
- add this plugin to both and run cordova build
- launch both onto a device from xcode and close both from xcode
- open app1 by tapping the icon on the device
- go to the home screen and open app2
then you see "app1" on the screen
Activity
shepsii commentedon Sep 7, 2018
reverting to 1.2.1 fixed it. But looks like an issue with the 2.x branch.
opiispanen commentedon Sep 17, 2018
We (our company) have also experienced this with our apps that updated to 2.x. We had version ^2.0.2 in the config.xml so it probably used the newest instead (last week).
Edit: experienced this only on ios.
masimplo commentedon Sep 17, 2018
This happened to me also. I got a support request from a completely confused user about this (I would be too, if I hadn't stumbled on this issue report as well).
I am guessing this due to some global state being kept between running different apps?
I am tempted to revert to 1.2.1 but am worried about down-migration issues it might have from 2.x to 1.x, as 2.x is already in production.
shepsii commentedon Sep 18, 2018
@masimplo makes a good point; whereas I saw this from two of my own apps, I strongly suspect it would apply to any two apps packaged using 2.x on any person's device. That's quite a nasty flaw and one that probably needs fixing with some degree of urgency.
FWIW I was able to revert to 1.2.1 and I didn't see any side effects of that at all.
mlynch commentedon Sep 28, 2018
We are aware of this issue and investigating. Thanks for hanging in there.
mlynch commentedon Sep 28, 2018
Quick update. We've got this patched in a test branch, but two things to keep in mind. First, make sure you choose a unique port using the
WKPort
option, that will keep your app listening on a port that another app is probably not. Second, the new changes introduce a transparent local authentication mechanism such that your app will only respond to requests from your app. We are testing these changes right now and will make a new release shortly.nphyatt commentedon Oct 4, 2018
Just released v2.2.0 which includes the changes from #186 and should fix this issue. Closing the issue now but feel free to open if you run into problems. Thanks for the report!
joewoodhouse commentedon Oct 10, 2018
Just to be clear, what happens in 2.2.0+ if two apps are using the same port? It doesn't seem fixed to me if there's a random chance that my app won't run whatsoever because another app happens to have chosen the same port as me. Will there be some sort of global registry of port numbers for users of this plugin (joke!)
sachingarg05 commentedon Oct 11, 2018
There should be an option for this plugin to not use the server etc, and just load from file:// URLs.
I believe this embedded server was added to workaround the cross-domain restrictions caused by WKWebView - but if an app does not run into those cross domain issues and does not want to open local port etc, it should be allowed as an option. Maybe it should also be the default option.
mlynch commentedon Oct 11, 2018
I don’t disagree. We also need to consider HTML5 routing
42 remaining items