[jira] [Commented] (CB-12074) Cookies are ignored on first application execution
[
https://issues.apache.org/jira/browse/CB-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180050#comment-16180050
]
Grant Patterson commented on CB-12074:
--
Well I've developed a workaround for AJAX/XHR requests. It's disgusting. :-(
I wrote a native-code XHR function that my javascript code can call. It makes
that call, then needs to wait at least 2 seconds before attempting further XHRs
within javascript. If I don't wait long enough, those XHRs all fail because no
cookies are remembered. But if it waits long enough, subsequent XHRs from
javascript will have the cookies that were received from the native-code XHR.
I filed a bug for this issue, which I think is separate from cookies working at
all: https://bugs.webkit.org/show_bug.cgi?id=177478
Native-code XHR implementation:
{code}
- (void)executeXHR:(CDVInvokedUrlCommand *)command {
NSString *urlStr = command.arguments[0];
NSURL *url = [NSURL URLWithString:urlStr];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
[request setHTTPMethod:@"GET"];
[request setValue:@"application/json" forHTTPHeaderField:@"Accept"];
[[[NSURLSession sharedSession] dataTaskWithRequest:request
completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable
response, NSError * _Nullable error) {
CDVPluginResult *result;
NSMutableDictionary *dict = [[NSMutableDictionary alloc] init];
NSHTTPURLResponse *httpResponse = nil;
if (response && [response isKindOfClass:[NSHTTPURLResponse class]]) {
httpResponse = (NSHTTPURLResponse*)response;
dict[@"statusCode"] = [NSNumber
numberWithInteger:httpResponse.statusCode];
}
if (data) {
dict[@"data"] = [[NSString alloc] initWithData:data
encoding:NSUTF8StringEncoding];
}
if (error) {
NSLog(@"executeXHR error: %@", error);
dict[@"error"] = [error localizedDescription];
if (httpResponse) {
NSLog(@"executeXHR error code: %d",
(int)httpResponse.statusCode);
}
result = [CDVPluginResult resultWithStatus:CDVCommandStatus_ERROR
messageAsDictionary:dict];
} else {
result = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK
messageAsDictionary:dict];
}
[self.commandDelegate sendPluginResult:result
callbackId:command.callbackId];
}] resume];
}
{code}
> Cookies are ignored on first application execution
> --
>
> Key: CB-12074
> URL: https://issues.apache.org/jira/browse/CB-12074
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-wkwebview-engine
> Environment: Cordova 5.4.0, iOS 9.3.5
>Reporter: Maxim
>Assignee: Shazron Abdullah
> Labels: wkwebview-known-issues
>
> Our application authenticates to the server. The server sets a 'JSESSIONID'
> cookie. The cookie is used by the server for session management.
> The issue is WKWebView does not send this cookie back to the server on
> subsequent requests. However, this only happens on first execution of the
> application, after its installation. Once the application closed and
> re-opened, the cookies are properly sent and authentication completes
> successfully.
> The problematic behavior is consistent, and was observed on several devices.
> On the other hand, there are no such issues with UIWebView.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12074) Cookies are ignored on first application execution
[ https://issues.apache.org/jira/browse/CB-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168706#comment-16168706 ] Grant Patterson commented on CB-12074: -- [~todd.miller] my experience as well. Can someone explain how AJAX/XHR requests are handled by the native code? Perhaps there's another way to intercept these and save the cookies returned by the server? FYI for me, the app doesn't need to be "closed" per se; simply backgrounding and foregrounding it makes things work. > Cookies are ignored on first application execution > -- > > Key: CB-12074 > URL: https://issues.apache.org/jira/browse/CB-12074 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-wkwebview-engine > Environment: Cordova 5.4.0, iOS 9.3.5 >Reporter: Maxim >Assignee: Shazron Abdullah > Labels: wkwebview-known-issues > > Our application authenticates to the server. The server sets a 'JSESSIONID' > cookie. The cookie is used by the server for session management. > The issue is WKWebView does not send this cookie back to the server on > subsequent requests. However, this only happens on first execution of the > application, after its installation. Once the application closed and > re-opened, the cookies are properly sent and authentication completes > successfully. > The problematic behavior is consistent, and was observed on several devices. > On the other hand, there are no such issues with UIWebView. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10728) Set-Cookie is ignored in WKWebViewEngine
[
https://issues.apache.org/jira/browse/CB-10728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058521#comment-16058521
]
Grant Patterson commented on CB-10728:
--
I'm having this problem, but a) only with AJAX calls and b) only in iOS
Simulator. I can work around it by setting document.location to my server's
login link, which breaks things (I'm navigating away from the file:// path that
runs my app) but logs in the WKWebView successfully. If I restart the app, the
WKWebView remembers the relevant cookies and is logged in, and I'm back at the
file:// path that runs the app properly.
> Set-Cookie is ignored in WKWebViewEngine
>
>
> Key: CB-10728
> URL: https://issues.apache.org/jira/browse/CB-10728
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-wkwebview-engine
> Environment: Cordova 5.4.0, Cordova-iOS 4.0.1, iOS 9.2.1
>Reporter: Sverre W
> Labels: iOS, triaged
>
> I'm trying to upgrade a cordova-ios 4.0.1 app, fully functioning with the old
> UIWebView, to use cordova-plugin-wkwebview-engine 1.0.2.
> The app does AJAX calls via jQuery, something like this:
> {code:javascript}
> $.ajax({
> crossDomain: true,
> xhrFields: {withCredentials: true},
> url: 'https://server.com/login',
> foo: "bar"
> });
> {code}
> After login, the server returns a set-cookie with an authorization token.
> This cookie is not included in subsequent requests when using WKWebView. It's
> simply ignored. I've tried multiple CORS configurations on the server, as
> liberal as possible, with no luck.
> Here are the 3 key requests (I'm omitting unrelated headers like {{Accept}},
> {{User-Agent}}:
> *Pre-flight OPTIONS*
> The webview sends an OPTIONS to the login URL with the headers
> * {{Origin: null}}
> * {{Access-Control-Request-Method: POST}}
> * {{Access-Control-Request-Headers: accept, origin, content-type}}
> The server responds with 200 OK and the headers
> * {{Access-Control-Allow-Origin: null}}
> * {{Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS}}
> * {{Access-Control-Allow-Headers: accept, origin, content-type}}
> * {{Access-Control-Allow-Credentials: true}}
> *Login POST*
> Now the webview sends the actual login request, with the header
> * {{Origin: null}}
> The server responds with 200 OK and the headers
> * {{Access-Control-Allow-Origin: null}}
> * {{Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS}}
> * {{Access-Control-Allow-Headers: accept, origin, content-type}}
> * {{Access-Control-Allow-Credentials: true}}
> * {{Set-Cookie: token=abc123; path=/; expires=Fri, 29-Apr-2017 12:49:06 GMT;
> HttpOnly}}
> *Authorized GET*
> After login the application believes it's logged in, and tries to access a
> restricted resource. However the only headers sent are {{Accept}},
> {{User-Agent}} and {{Origin}}. No {{Cookie}}.
>
> Google returns vaguely similar issues around WKWebView and cookies, some of
> them from the Telerik plugin, but I see no concrete evidence that anyone has
> gotten this kind of auth flow to work. Even though it does in UIWebView. Is
> it simply not supported? Am I missing some obscure CORS detail? Either way,
> maybe it should be documented somewhere.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12838) Order of plugins in config.xml modified during build
[ https://issues.apache.org/jira/browse/CB-12838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048322#comment-16048322 ] Grant Patterson commented on CB-12838: -- This is also a big headache for version control: when the order of config.xml elements change, the file appears modified when it has not substantively changed. > Order of plugins in config.xml modified during build > > > Key: CB-12838 > URL: https://issues.apache.org/jira/browse/CB-12838 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-cli >Affects Versions: cordova@7.0.0 > Environment: Mac OS 10.12.4, Cordova 7.0.1 >Reporter: Anton Weber >Priority: Minor > Labels: android, ios > > Running cordova build android or cordova build ios changes the order in which > plugins are listed in the config.xml (arranging them alphabetically). > This causes problems when manually resolving dependencies, e.g. when > installing a specific version of a dependency first by having it higher up in > the list. > Example: > Original config.xml content: > ... > > > > > > ... > After cordova build: > ... > > > > > > ... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12846) WebView JS execution continues when app executes in background
[ https://issues.apache.org/jira/browse/CB-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037808#comment-16037808 ] Grant Patterson commented on CB-12846: -- Well I don't understand [~shazron]'s comment...but switching to using WKWebView fixes the issue for me. > WebView JS execution continues when app executes in background > -- > > Key: CB-12846 > URL: https://issues.apache.org/jira/browse/CB-12846 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Affects Versions: cordova-ios@4.3.1 >Reporter: Grant Patterson > > I'm using a [Cordova > plugin|https://github.com/happydenn/cordova-plugin-gimbal2] that integrates > [a third-party SDK|https://docs.gimbal.com/iosdocs/v2/devguide.html] to > listen for bluetooth beacon sighting events. As expected, my app is allowed > to run for 10 seconds in the background with the [bluetooth-central > UIBackgroundMode|https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html]. > Once the necessary processing is completed, the JS event loop runs until the > 10-second window closes. Because beacon sightings happen as frequently as > several per second, the app runs in the background constantly, killing the > user's battery. I can setInterval() in JS with a 1000ms interval and it runs > successfully every time; my Angular app runs $digest cycles in the background > which are unnecessary and quite expensive. > I think I need a way for the native plugin code to relinquish execution and > return the app to the background. > StackOverflow: > [https://stackoverflow.com/questions/44145031/stopping-background-javascript-activity-on-location-triggered-bluetooth-central] -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-12846) WebView JS execution continues when app executes in background
Grant Patterson created CB-12846: Summary: WebView JS execution continues when app executes in background Key: CB-12846 URL: https://issues.apache.org/jira/browse/CB-12846 Project: Apache Cordova Issue Type: Bug Components: cordova-ios Affects Versions: cordova-ios@4.3.1 Reporter: Grant Patterson I'm using a [Cordova plugin|https://github.com/happydenn/cordova-plugin-gimbal2] that integrates [a third-party SDK|https://docs.gimbal.com/iosdocs/v2/devguide.html] to listen for bluetooth beacon sighting events. As expected, my app is allowed to run for 10 seconds in the background with the [bluetooth-central UIBackgroundMode|https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html]. Once the necessary processing is completed, the JS event loop runs until the 10-second window closes. Because beacon sightings happen as frequently as several per second, the app runs in the background constantly, killing the user's battery. I can setInterval() in JS with a 1000ms interval and it runs successfully every time; my Angular app runs $digest cycles in the background which are unnecessary and quite expensive. I think I need a way for the native plugin code to relinquish execution and return the app to the background. StackOverflow: [https://stackoverflow.com/questions/44145031/stopping-background-javascript-activity-on-location-triggered-bluetooth-central] -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-11044) files modified by after_prepare hook are reverted when restoring plugins
[
https://issues.apache.org/jira/browse/CB-11044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235827#comment-15235827
]
Grant Patterson commented on CB-11044:
--
Neither changing the hook type nor calling {{cordova prepare}} appears to
workaround the problem. After both {{cordova prepare}} and {{cordova build}},
the changes made by the hook have been reverted.
For now I'm working around by downgrading to 5.3.3 :-/
> files modified by after_prepare hook are reverted when restoring plugins
>
>
> Key: CB-11044
> URL: https://issues.apache.org/jira/browse/CB-11044
> Project: Apache Cordova
> Issue Type: Bug
> Components: CordovaLib
>Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
> Environment: OSX 10.11.4, also happens in Greenhouse CI tool
>Reporter: Grant Patterson
>Assignee: Vladimir Kotikov
> Labels: Android, iOS, triaged
>
> I have a hook that uses the {{fs}} module functions {{readFileSync}} and
> {{writeFileSync}} to modify files in the platforms/ directory. I'm using a
> hook only barely modified from {{020_replace_text.js}} in these examples, to
> which the most recent Cordova documentation links:
> http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
> The CLI command I use is {{cordova run ios}} (also android)
> It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
> it wrote the file properly, and I can re-{{readFileSync}} to confirm this,
> but the write does not appear to stick. When the build is over, the file has
> reverted to its pre-hook state and the built app does not have the change.
> I have tried wrapping my hook in:
> {{module.exports = function(context) {}}
> as the documentation suggests. I also moved the hook to scripts/ and tried
> referencing it in config.xml, since the hooks/ directory is deprecated. None
> of these seem to make any difference. It seems that anything in the www/
> directory has this issue, as well as platforms/android/AndroidManifest.xml.
> If I write to a new file in the same directory, the file does not persist,
> so it must be the whole directory that's being overwritten. If I raise an
> exception in the hook, the build fails and the file remains properly
> modified. So it's definitely something after this hook executes that undoes
> it.
> Interesting development: It's something to do with my plugins; it doesn't
> happen in a small sample project. I use {{}} entries in config.xml to
> define which plugins should be installed. When I delete these entries—without
> actually removing any of the plugins!—this issue doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-11044) files modified by after_prepare hook are reverted
[
https://issues.apache.org/jira/browse/CB-11044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232988#comment-15232988
]
Grant Patterson commented on CB-11044:
--
Sure, thanks for looking into it. I can reproduce with an example app.
This example app uses the iBeacon plugin:
https://github.com/mikaelkindborg/evo-demos/tree/master/Demos2015/cordova-ibeacon
Running {{cordova plugin add
https://github.com/petermetz/cordova-plugin-ibeacon#3.3.0}} as stated in the
README works fine; the plugin is added and builds into the app as expected, and
a simple hook to hack index.html (pasted below) works fine.
BUT when I add this line to config.xml:
{{https://github.com/petermetz/cordova-plugin-ibeacon; />}}
the hook fails. Let me know if I can help you reproduce. I will be looking into
the specifics of what the plugin does...
Here's the hook I'm using in hooks/after_prepare/:
#!/usr/bin/env node
// this plugin replaces arbitrary text in arbitrary files
// right now it replaces all instances of "script" in index.html with "SCRIPTY",
// breaking everything. ;-)
var fs = require('fs');
var path = require('path');
var rootdir = process.argv[2];
console.log("rootdir", rootdir, process.argv);
function replace_string_in_file(filename, to_replace, replace_with) {
var data = fs.readFileSync(filename, 'utf8');
var result = data.replace(new RegExp(to_replace, "g"), replace_with);
console.log(">RESULT\n", result, "\n>\n");
fs.writeFileSync(filename, result, 'utf8');
}
if (rootdir) {
var filestoreplace = [
// android
"platforms/android/assets/www/index.html",
// ios
"platforms/ios/www/index.html",
];
filestoreplace.forEach(function(val, index, array) {
var fullfilename = path.join(rootdir, val);
if (fs.existsSync(fullfilename)) {
console.log("patching: "+fullfilename);
// CONFIGURE HERE
replace_string_in_file(fullfilename,
"script",
'SCRIPTY');
} else {
console.log("missing: "+fullfilename);
}
});
}
> files modified by after_prepare hook are reverted
> -
>
> Key: CB-11044
> URL: https://issues.apache.org/jira/browse/CB-11044
> Project: Apache Cordova
> Issue Type: Bug
> Components: CordovaLib
>Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
> Environment: OSX 10.11.4, also happens in Greenhouse CI tool
>Reporter: Grant Patterson
>Assignee: Vladimir Kotikov
> Labels: Android, iOS
>
> I have a hook that uses the {{fs}} module functions {{readFileSync}} and
> {{writeFileSync}} to modify files in the platforms/ directory. I'm using a
> hook only barely modified from {{020_replace_text.js}} in these examples, to
> which the most recent Cordova documentation links:
> http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
> The CLI command I use is {{cordova run ios}} (also android)
> It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
> it wrote the file properly, and I can re-{{readFileSync}} to confirm this,
> but the write does not appear to stick. When the build is over, the file has
> reverted to its pre-hook state and the built app does not have the change.
> I have tried wrapping my hook in:
> {{module.exports = function(context) {}}
> as the documentation suggests. I also moved the hook to scripts/ and tried
> referencing it in config.xml, since the hooks/ directory is deprecated. None
> of these seem to make any difference. It seems that anything in the www/
> directory has this issue, as well as platforms/android/AndroidManifest.xml.
> If I write to a new file in the same directory, the file does not persist,
> so it must be the whole directory that's being overwritten. If I raise an
> exception in the hook, the build fails and the file remains properly
> modified. So it's definitely something after this hook executes that undoes
> it.
> Interesting development: It's something to do with my plugins; it doesn't
> happen in a small sample project. I use {{}} entries in config.xml to
> define which plugins should be installed. When I delete these entries—without
> actually removing any of the plugins!—this issue doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-11044) files modified by after_prepare hook are reverted
[
https://issues.apache.org/jira/browse/CB-11044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Patterson resolved CB-11044.
--
Resolution: Not A Bug
Turns out this has something to do with this plugin:
https://github.com/petermetz/cordova-plugin-ibeacon
so I will investigate further and open a new bug if/when/where I can find the
real issue.
> files modified by after_prepare hook are reverted
> -
>
> Key: CB-11044
> URL: https://issues.apache.org/jira/browse/CB-11044
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, iOS
>Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
> Environment: OSX 10.11.4, also happens in Greenhouse CI tool
>Reporter: Grant Patterson
>
> I have a hook that uses the {{fs}} module functions {{readFileSync}} and
> {{writeFileSync}} to modify files in the platforms/ directory. I'm using a
> hook only barely modified from {{020_replace_text.js}} in these examples, to
> which the most recent Cordova documentation links:
> http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
> The CLI command I use is {{cordova run ios}} (also android)
> It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
> it wrote the file properly, and I can re-{{readFileSync}} to confirm this,
> but the write does not appear to stick. When the build is over, the file has
> reverted to its pre-hook state and the built app does not have the change.
> I have tried wrapping my hook in:
> {{module.exports = function(context) {}}
> as the documentation suggests. I also moved the hook to scripts/ and tried
> referencing it in config.xml, since the hooks/ directory is deprecated. None
> of these seem to make any difference. It seems that anything in the www/
> directory has this issue, as well as platforms/android/AndroidManifest.xml.
> If I write to a new file in the same directory, the file does not persist,
> so it must be the whole directory that's being overwritten. If I raise an
> exception in the hook, the build fails and the file remains properly
> modified. So it's definitely something after this hook executes that undoes
> it.
> Interesting development: It's something to do with my plugins; it doesn't
> happen in a small sample project. I use {{}} entries in config.xml to
> define which plugins should be installed. When I delete these entries—without
> actually removing any of the plugins!—this issue doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-11044) files modified by after_prepare hook are reverted
[
https://issues.apache.org/jira/browse/CB-11044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Patterson updated CB-11044:
-
Description:
I have a hook that uses the {{fs}} module functions {{readFileSync}} and
{{writeFileSync}} to modify files in the platforms/ directory. I'm using a hook
only barely modified from {{020_replace_text.js}} in these examples, to which
the most recent Cordova documentation links:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
The CLI command I use is {{cordova run ios}} (also android)
It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
it wrote the file properly, and I can re-{{readFileSync}} to confirm this, but
the write does not appear to stick. When the build is over, the file has
reverted to its pre-hook state and the built app does not have the change.
I have tried wrapping my hook in:
{{module.exports = function(context) {}}
as the documentation suggests. I also moved the hook to scripts/ and tried
referencing it in config.xml, since the hooks/ directory is deprecated. None of
these seem to make any difference. It seems that anything in the www/ directory
has this issue, as well as platforms/android/AndroidManifest.xml.
If I write to a new file in the same directory, the file does not persist, so
it must be the whole directory that's being overwritten. If I raise an
exception in the hook, the build fails and the file remains properly modified.
So it's definitely something after this hook executes that undoes it.
Interesting development: It's something to do with my plugins; it doesn't
happen in a small sample project. I use {{}} entries in config.xml to
define which plugins should be installed. When I delete these entries—without
actually removing any of the plugins!—this issue doesn't happen.
was:
I have a hook that uses the {{fs}} module functions {{readFileSync}} and
{{writeFileSync}} to modify files in the platforms/ directory. I'm using a hook
only barely modified from {{020_replace_text.js}} in these examples, to which
the most recent Cordova documentation links:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
The CLI command I use is {{cordova run ios}} (also android)
It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
it wrote the file properly, and I can re-{{readFileSync}} to confirm this, but
the write does not appear to stick. When the build is over, the file has
reverted to its pre-hook state and the built app does not have the change.
I have tried wrapping my hook in:
{{module.exports = function(context) {}}
as the documentation suggests. I also moved the hook to scripts/ and tried
referencing it in config.xml, since the hooks/ directory is deprecated. None of
these seem to make any difference. It seems that anything in the www/ directory
has this issue, as well as platforms/android/AndroidManifest.xml.
If I write to a new file in the same directory, the file does not persist, so
it must be the whole directory that's being overwritten. If I raise an
exception in the hook, the build fails and the file remains properly modified.
So it's definitely something after this hook executes that undoes it.
> files modified by after_prepare hook are reverted
> -
>
> Key: CB-11044
> URL: https://issues.apache.org/jira/browse/CB-11044
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, iOS
>Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
> Environment: OSX 10.11.4, also happens in Greenhouse CI tool
>Reporter: Grant Patterson
>
> I have a hook that uses the {{fs}} module functions {{readFileSync}} and
> {{writeFileSync}} to modify files in the platforms/ directory. I'm using a
> hook only barely modified from {{020_replace_text.js}} in these examples, to
> which the most recent Cordova documentation links:
> http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
> The CLI command I use is {{cordova run ios}} (also android)
> It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
> it wrote the file properly, and I can re-{{readFileSync}} to confirm this,
> but the write does not appear to stick. When the build is over, the file has
> reverted to its pre-hook state and the built app does not have the change.
> I have tried wrapping my hook in:
> {{module.exports = function(context) {}}
> as the documentation suggests. I also moved the hook to scripts/ and tried
> referencing it in config.xml, since the hooks/ directory is deprecated. None
> of these seem to make any difference. It seems that anything in the www/
> directory has this issue, as well as platforms/android/AndroidManifest.xml.
> If I write to a new file in the same
[jira] [Updated] (CB-11044) files modified by after_prepare hook are reverted
[
https://issues.apache.org/jira/browse/CB-11044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Patterson updated CB-11044:
-
Description:
I have a hook that uses the {{fs}} module functions {{readFileSync}} and
{{writeFileSync}} to modify files in the platforms/ directory. I'm using a hook
only barely modified from {{020_replace_text.js}} in these examples, to which
the most recent Cordova documentation links:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
The CLI command I use is {{cordova run ios}} (also android)
It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
it wrote the file properly, and I can re-{{readFileSync}} to confirm this, but
the write does not appear to stick. When the build is over, the file has
reverted to its pre-hook state and the built app does not have the change.
I have tried wrapping my hook in:
{{module.exports = function(context) {}}
as the documentation suggests. I also moved the hook to scripts/ and tried
referencing it in config.xml, since the hooks/ directory is deprecated. None of
these seem to make any difference. It seems that anything in the www/ directory
has this issue, as well as platforms/android/AndroidManifest.xml.
If I write to a new file in the same directory, the file does not persist, so
it must be the whole directory that's being overwritten. If I raise an
exception in the hook, the build fails and the file remains properly modified.
So it's definitely something after this hook executes that undoes it.
was:
I have a hook that uses the {{fs}} module functions {{readFileSync}} and
{{writeFileSync}} to modify files in the platforms/ directory. I'm using a hook
only barely modified from {{020_replace_text.js}} in these examples, to which
the most recent Cordova documentation links:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
The CLI command I use is {{cordova run ios}} (also android)
It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
it wrote the file properly, and I can re-{{readFileSync}} to confirm this, but
the write does not appear to stick. When the build is over, the file has
reverted to its pre-hook state and the built app does not have the change.
I have tried wrapping my hook in:
{{module.exports = function(context) {}}
as the documentation suggests. I also moved the hook to scripts/ and tried
referencing it in config.xml, since the hooks/ directory is deprecated. None of
these seem to make any difference. It seems that anything in the www/ directory
has this issue, as well as platforms/android/AndroidManifest.xml.
> files modified by after_prepare hook are reverted
> -
>
> Key: CB-11044
> URL: https://issues.apache.org/jira/browse/CB-11044
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, iOS
>Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
> Environment: OSX 10.11.4, also happens in Greenhouse CI tool
>Reporter: Grant Patterson
>
> I have a hook that uses the {{fs}} module functions {{readFileSync}} and
> {{writeFileSync}} to modify files in the platforms/ directory. I'm using a
> hook only barely modified from {{020_replace_text.js}} in these examples, to
> which the most recent Cordova documentation links:
> http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
> The CLI command I use is {{cordova run ios}} (also android)
> It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
> it wrote the file properly, and I can re-{{readFileSync}} to confirm this,
> but the write does not appear to stick. When the build is over, the file has
> reverted to its pre-hook state and the built app does not have the change.
> I have tried wrapping my hook in:
> {{module.exports = function(context) {}}
> as the documentation suggests. I also moved the hook to scripts/ and tried
> referencing it in config.xml, since the hooks/ directory is deprecated. None
> of these seem to make any difference. It seems that anything in the www/
> directory has this issue, as well as platforms/android/AndroidManifest.xml.
> If I write to a new file in the same directory, the file does not persist,
> so it must be the whole directory that's being overwritten. If I raise an
> exception in the hook, the build fails and the file remains properly
> modified. So it's definitely something after this hook executes that undoes
> it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-11044) files modified by after_prepare hook are reverted
Grant Patterson created CB-11044:
Summary: files modified by after_prepare hook are reverted
Key: CB-11044
URL: https://issues.apache.org/jira/browse/CB-11044
Project: Apache Cordova
Issue Type: Bug
Components: Android, iOS
Affects Versions: 5.4.0, 6.0.0, 5.4.1, 6.0.1, 6.1.0, 6.1.1
Environment: OSX 10.11.4, also happens in Greenhouse CI tool
Reporter: Grant Patterson
I have a hook that uses the {{fs}} module functions {{readFileSync}} and
{{writeFileSync}} to modify files in the platforms/ directory. I'm using a hook
only barely modified from {{020_replace_text.js}} in these examples, to which
the most recent Cordova documentation links:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/
The CLI command I use is {{cordova run ios}} (also android)
It all works fine in Cordova 5.3.3, but starting with 5.4.0 the hook *thinks*
it wrote the file properly, and I can re-{{readFileSync}} to confirm this, but
the write does not appear to stick. When the build is over, the file has
reverted to its pre-hook state and the built app does not have the change.
I have tried wrapping my hook in:
{{module.exports = function(context) {}}
as the documentation suggests. I also moved the hook to scripts/ and tried
referencing it in config.xml, since the hooks/ directory is deprecated. None of
these seem to make any difference. It seems that anything in the www/ directory
has this issue, as well as platforms/android/AndroidManifest.xml.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-9208) InAppBrowser.executeScript interacts strangely with location.hash
[ https://issues.apache.org/jira/browse/CB-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592299#comment-14592299 ] Grant Patterson commented on CB-9208: - Experimenting more, I'm thinking it isn't about which kind of page load this is, but a timing issue. If I create a timeout for my executeScript() call, the callback is executed if the delay is 300ms, but not if the delay is 30ms. That makes some sense: I can always call executeScript() on an in-app browser instance, but if it's transitioning from one page to the next, there's a sort of race condition: on which page should the js be executed? Nevertheless, it still seems strange to me that the callback would be simply dropped, especially when the code is still executed. And indeed, there must be some strange interaction with the location hash, since in that case there isn't a new page anyway, just a different section, so is it really a new context at all? InAppBrowser.executeScript interacts strangely with location.hash - Key: CB-9208 URL: https://issues.apache.org/jira/browse/CB-9208 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 5.0.0 Environment: iOS Reporter: Grant Patterson In my loadstart event handler I call executeScript() with a callback. Here is what I see: actual page change: script runs, callback runs window.location.assign(same page, new hash): nothing runs click anchor link e.g. href=#newsection: nothing runs set location.hash = newhash: script runs; callback does not The last case is the strangest to me. The script runs just fine in this case but the callback with the result never happens. I'm not sure under what conditions a URL fragment change should trigger the loadstart event; I would say it should be always, and that does not appear to be the case. That is probably a bug. Worse, though, is running the script but not triggering its callback. This could leave some task half-done: the in-app-browser window has had a state change, but the code outside the in-app-browser never hears back about it. That is almost certainly a bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-9208) InAppBrowser.executeScript interacts strangely with location.hash
Grant Patterson created CB-9208: --- Summary: InAppBrowser.executeScript interacts strangely with location.hash Key: CB-9208 URL: https://issues.apache.org/jira/browse/CB-9208 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 5.0.0 Environment: iOS Reporter: Grant Patterson In my loadstart event handler I call executeScript() with a callback. Here is what I see: actual page change: script runs, callback runs window.location.assign(same page, new hash): nothing runs click anchor link e.g. href=#newsection: nothing runs set location.hash = newhash: script runs; callback does not The last case is the strangest to me. The script runs just fine in this case but the callback with the result never happens. I'm not sure under what conditions a URL fragment change should trigger the loadstart event; I would say it should be always, and that does not appear to be the case. That is probably a bug. Worse, though, is running the script but not triggering its callback. This could leave some task half-done: the in-app-browser window has had a state change, but the code outside the in-app-browser never hears back about it. That is almost certainly a bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
