[jira] [Commented] (CB-4742) storage.spec.18 fails if storage plugin is used

["Peter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CB-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13761561#comment-13761561 ] 

Peter commented on CB-4742:
---------------------------

@Joe: Here is some more information:

If we add some debugging alert to to cordova.js 

{code}
var originalOpenDatabase = modulemapper.getOriginalSymbol(window, 'openDatabase');

module.exports = function(name, version, desc, size) {
    // First patch WebSQL if necessary
    if (!originalOpenDatabase) {
        // Not defined, create an openDatabase function for all to use!
        alert('DEBUG: openDatabase not defined. Use plugin');
        return storage.openDatabase.apply(this, arguments);
    }
    ...
{code}

then my Cordova application it behaves differently depending how it is run:

* The *normal* mobile-spec cordova app doesn't get to the alert - it's using the native openDatabase

* If the mobile-spec app is *embedded in a CordovaWebView* (eg http://cordova.apache.org/docs/en/3.0.0/guide_platforms_android_webview.md.html#Android%20WebViews) then it always outputs the alert - so it's using the Cordova plugin implementation.

--

Q. Is this because of the namespace problem that you described?

Q. Can you please provide some reference about that namespace problem you described so we could learn more about it?

Thanks.

                
> storage.spec.18 fails if storage plugin is used
> -----------------------------------------------
>
>                 Key: CB-4742
>                 URL: https://issues.apache.org/jira/browse/CB-4742
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android, CordovaJS, mobile-spec
>    Affects Versions: 2.9.0
>         Environment: Samsung Galaxy Tab - Android 4.0.3
>            Reporter: Peter
>            Assignee: Joe Bowser
>
> The mobile-spec test for storage.spec.18 can fail if the storage plugin is used.
> Failure happens during DROP and says "no such table: foo2 (code 1)" because it is attempting the DROP foo2 before the CREATE foo2 has happened.
> It seems caused by the same issue reported here: https://issues.apache.org/jira/browse/CB-3047. Transaction success callback is called prematurely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira