Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests fail on iOS when WKWebView plugin is present #52

Closed
dpa99c opened this issue Oct 8, 2018 · 8 comments
Closed

Tests fail on iOS when WKWebView plugin is present #52

dpa99c opened this issue Oct 8, 2018 · 8 comments
Labels

Comments

@dpa99c
Copy link

dpa99c commented Oct 8, 2018

Currently, if you add cordova-plugin-wkwebview-engine as a plugin dependency to the tests/plugin.xml of a plugin then run the tests against the iOS platform using cordova-paramedic, they will fail because the local server times out waiting for a connection, despite the tests actually passing in the Simulator.

As highlighted in my comment, this is causing the Travis CI tests to fail for my PR to add WKWebView support to cordova-plugin-inappbrowser.

With UIWebView being deprecated in iOS 12 and the intention to add implicit WKWebView support to cordova-ios@5, there is a need to resolve this issue other than to unblock my PR.

Travis CI console output

cordova-paramedic: connecting webdriver
.........................................................................................
cordova-paramedic: connecting to app
cordova-paramedic: waiting for test results
cordova-paramedic: Tests failed to complete; ending appium session. The error is:
Error: waitForTests: Seems like device not connected to local server in 540 secs
    at null._onTimeout (/private/tmp/paramedic/lib/paramedic.js:467:24)
    at Timer.listOnTimeout (timers.js:92:15)
Running Appium tests on Sauce Labs
Couldn't find Appium tests, skipping...
Completed tests at 3:26:19 PM
Getting saucelabs jobs details...
============================================================================================
Job name: travis-plugin-inappbrowser-528.5
Job ID: 9e9fe12e7103401daeb12a776de27920
Job URL: https://saucelabs.com/beta/tests/9e9fe12e7103401daeb12a776de27920
Video: https://assets.saucelabs.com/jobs/9e9fe12e7103401daeb12a776de27920/video.flv
Appium logs: https://assets.saucelabs.com/jobs/9e9fe12e7103401daeb12a776de27920/selenium-server.log
============================================================================================
============================================================================================
Job name: travis-plugin-inappbrowser-528.5
Job ID: c55b39dde835418284afaa722caac636
Job URL: https://saucelabs.com/beta/tests/c55b39dde835418284afaa722caac636
Video: https://assets.saucelabs.com/jobs/c55b39dde835418284afaa722caac636/video.flv
Appium logs: https://assets.saucelabs.com/jobs/c55b39dde835418284afaa722caac636/selenium-server.log
============================================================================================
local-server: killing local file transfer server if it's up...
cordova-paramedic: Deleting the application: /var/folders/bb/n7t3rs157850byt_jfdcq9k80000gn/T/tmp-2328OlO9Er6tnA8D
/Users/travis/build/apache/cordova-plugin-inappbrowser
Finished with exit code 1
The command "node /tmp/paramedic/main.js --config pr/$PLATFORM --plugin $(pwd) --shouldUseSauce --buildName travis-plugin-inappbrowser-$TRAVIS_JOB_NUMBER" exited with 1.
Done. Your build exited with 1.

@knight9999
Copy link
Contributor

knight9999 commented Oct 9, 2018

I reproduced this issue.
I found that both medic.js in cordova-plugin-test-framework and paramedic.js in paramedic-plugin calls ../medic.json like

        var xhr = new XMLHttpRequest();
        xhr.open("GET", "../medic.json", false);
        xhr.send(null);
        var cfg = JSON.parse(xhr.responseText);

However this HttpRequest fails in WKWebView.

I found the following error

Crosss origin requests are only supported for HTTP.

Here are my screenshots

2018-10-09 14 22 43
2018-10-09 14 23 06

@knight9999
Copy link
Contributor

knight9999 commented Oct 9, 2018

If I edit cordova-plugin-wkwebview-engine in my local environment as

diff --git a/src/ios/CDVWKWebViewEngine.m b/src/ios/CDVWKWebViewEngine.m
index e6778c8..eec3b60 100644
--- a/src/ios/CDVWKWebViewEngine.m
+++ b/src/ios/CDVWKWebViewEngine.m
@@ -97,6 +97,7 @@
 
     // re-create WKWebView, since we need to update configuration
     WKWebView* wkWebView = [[WKWebView alloc] initWithFrame:self.engineWebView.frame configuration:configuration];
+    [wkWebView.configuration.preferences setValue:@YES forKey:@"allowFileAccessFromFileURLs"];
 
 #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000
     if (@available(iOS 11.0, *)) {

and edit tests/plugin in cordova-paramedic to use this custom WKWebViewEngine like

      <dependency id="cordova-plugin-wkwebview-engine" url="/Users/knaito/Documents/work/cordova-develop/cordova-plugin-wkwebview-engine" />

(url is the custom WkWebView plugin location in your mac)

npm run test-ios command works successfully.

However allowFileAccessFromFileURLs is a private API.
Apple may rejects the application using allowFileAccessFromFileURLs.

@knight9999
Copy link
Contributor

knight9999 commented Oct 9, 2018

I created a plugin to support cordova-paramedic test in iOS: https://github.com/knight9999/cordova-plugin-wkwebview-engine-allowfileaccess

Could you please try to use this plugin as

    <platform name="ios">
      <dependency id="cordova-plugin-wkwebview-engine" />
      <dependency id="cordova-plugin-wkwebview-engine-allowfileaccess" url="https://github.com/knight9999/cordova-plugin-wkwebview-engine-allowfileaccess.git" />
    </platform>

in tests/plugin.xml in cordova-paramedic ?

dpa99c added a commit to dpa99c/cordova-plugin-themeablebrowser that referenced this issue Oct 9, 2018
@dpa99c
Copy link
Author

dpa99c commented Oct 9, 2018

Yep, works great, Travis tests are now passing.

@knight9999
Copy link
Contributor

knight9999 commented Oct 9, 2018

So nice.
My plugin (https://github.com/knight9999/cordova-plugin-wkwebview-engine-allowfileaccess.git ) is very experimental and not published to npm repository.

If this works, it is better to create a new plugin in cordova-paramedic's spec folder and use that plugin instead of my plugin.

@janpio
Copy link
Member

janpio commented Oct 30, 2018

(Great work @knight9999!)

Seems like a good idea to create an additional plugin in spec so it is easier to be used by @dpa99c.

@janpio janpio added the bug label Nov 24, 2018
@janpio
Copy link
Member

janpio commented Dec 5, 2018

@knight9999 I think your plugin should actually not live in spec but directly in this repo. spec contains the plugin to be used to test paramedic itself, like testable-plugin that just makes sure the communication between paramedic and the app/plugin works.

That being said, the way @dpa99c currently included the plugin doesn't really match how e.g. ios-geolocation-permissions-plugin is included to make the geolocation plugin work on iOS:

if (this.config.getPlatformId() === util.IOS) {
additionalPlugins.push(path.join(__dirname, '../ios-geolocation-permissions-plugin'));
}

There are multiple of those:

if (this.config.shouldUseSauce() && !this.config.getUseTunnel()) {
additionalPlugins.push(path.join(__dirname, '../event-cache-plugin'));
}
if (this.config.getPlatformId() === util.WINDOWS) {
additionalPlugins.push(path.join(__dirname, '../debug-mode-plugin'));
}
if (this.config.getPlatformId() === util.IOS) {
additionalPlugins.push(path.join(__dirname, '../ios-geolocation-permissions-plugin'));
}
if (this.config.isCI()) {
additionalPlugins.push(path.join(__dirname, '../ci-plugin'));
}

Those are the ones that are included here in this repo.

I think @dpa99c should probably include the plugin in "his" own test folder to make it work best - or it stays in a separate repo.

@erisu
Copy link
Member

erisu commented Sep 24, 2021

Closing out this issue as the WKWebView plugin was deprecated.

@erisu erisu closed this as completed Sep 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants