Apache Cordova
  1. Apache Cordova
  2. CB-837

CaptureCB - mediaFile.fullPath does not resolve to file

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.7.0
    • Fix Version/s: None
    • Component/s: Plugin Media
    • Labels:
    • Environment:

      Tested on iOS

      Description

      Hey there,

      Simply put here is an example

      navigator.device.capture.captureAudio(successCB, error,

      {limit: 1}

      );

      function successCB(mediaFile)

      { window.resolveLocalFileSystemURI(mediaFile[0].fullPath, gotFileEntry, fsFail); }

      function fsFail(error)

      { alert('we failed with code ' + error.code); //5 }

      The issue is mediaFile[0].fullPath lacks file://localhost being prepended. Is this intentional?

      Simple work around is just to add it in using

      var path = mediaFile[0].fullPath

      if(path.indexOf("file://localhost") == -1) path = "file://localhost" + path;

        Activity

        Hide
        Simon MacDonald added a comment -

        This is a good find. We should make this consistent across the API's as the Camera and File API's return the protocol in front of the path. I checked on Android and it also has this inconsistent behaviour.

        Show
        Simon MacDonald added a comment - This is a good find. We should make this consistent across the API's as the Camera and File API's return the protocol in front of the path. I checked on Android and it also has this inconsistent behaviour.
        Hide
        Dimitri Adamou added a comment -

        Yeah I would like to note that if you wish to play recorded sounds, you'll need to do the same thing.

        var path = mediaFile[0].fullPath
        if(path.indexOf("file://localhost") == -1) path = "file://localhost" + path;
        var media = new Media(path, mediaSuccess, [mediaError], [mediaStatus]);

        Otherwise you get a 'cannot use this resource' error

        Show
        Dimitri Adamou added a comment - Yeah I would like to note that if you wish to play recorded sounds, you'll need to do the same thing. var path = mediaFile [0] .fullPath if(path.indexOf("file://localhost") == -1) path = "file://localhost" + path; var media = new Media(path, mediaSuccess, [mediaError] , [mediaStatus] ); Otherwise you get a 'cannot use this resource' error
        Hide
        Simon MacDonald added a comment -

        I've put in a fix for Android which should be available in 1.8.0. I've asked Becky and Drew to propagate the fix to iOS and BB.

        Show
        Simon MacDonald added a comment - I've put in a fix for Android which should be available in 1.8.0. I've asked Becky and Drew to propagate the fix to iOS and BB.
        Hide
        Drew Walters added a comment -

        Confirmed that BB does not exhibit this issue. All capture results are prefixed with "file://" URI protocol when passed back to JS layer.

        Show
        Drew Walters added a comment - Confirmed that BB does not exhibit this issue. All capture results are prefixed with "file://" URI protocol when passed back to JS layer.
        Hide
        Becky Gibson added a comment -

        This is bigger than just adding file://localhost to the path. I will also have to update all of the iOS file api's to expect that an incoming path may contain file://localhost since people may use these paths with the file api. Seems like too big of a fix in the middle of a release candidate.

        Show
        Becky Gibson added a comment - This is bigger than just adding file://localhost to the path. I will also have to update all of the iOS file api's to expect that an incoming path may contain file://localhost since people may use these paths with the file api. Seems like too big of a fix in the middle of a release candidate.
        Hide
        Simon MacDonald added a comment -

        When Fil dropped the common JS into the Android repo all fullPath's had to start with the file:// protocol or it would just fail horribly. I'm surprised the same did not happen for you.

        This is actually beneficial on the Android side as now mediaFile.fullPath can be passed to window.resolveLocalFileSystemURI() to get a FileEntry object. Pretty much every other API on the Android side returns a URL as a full path to any file.

        Show
        Simon MacDonald added a comment - When Fil dropped the common JS into the Android repo all fullPath's had to start with the file:// protocol or it would just fail horribly. I'm surprised the same did not happen for you. This is actually beneficial on the Android side as now mediaFile.fullPath can be passed to window.resolveLocalFileSystemURI() to get a FileEntry object. Pretty much every other API on the Android side returns a URL as a full path to any file.
        Hide
        Becky Gibson added a comment -

        I did a quick test on Chrome Version 19.0.1084.52

        This code:
        function doTest()

        { window.webkitRequestFileSystem(TEMPORARY, 0, gotFS, fail); }


        function gotFS(fileSystem) {
        fileSystem.root.getFile("readme.txt",

        {create: true}

        ,
        gotFileEntry, fail);
        }
        function gotFileEntry(fileEntry)

        { console.log("Entry.fullPath: " + fileEntry.fullPath); console.log("Entry.toURL(): " + fileEntry.toURL()); }

        function fail(error)

        { console.log("file fail"); console.log(error.message); }

        returns:
        Entry.fullPath: /readme.txt
        Entry.toURL(): filesystem:file:///temporary/readme.txt

        Which doesn't mean we shouldn't change our fullPath but I think we at least need to take other implementations into consideration.

        Show
        Becky Gibson added a comment - I did a quick test on Chrome Version 19.0.1084.52 This code: function doTest() { window.webkitRequestFileSystem(TEMPORARY, 0, gotFS, fail); } function gotFS(fileSystem) { fileSystem.root.getFile("readme.txt", {create: true} , gotFileEntry, fail); } function gotFileEntry(fileEntry) { console.log("Entry.fullPath: " + fileEntry.fullPath); console.log("Entry.toURL(): " + fileEntry.toURL()); } function fail(error) { console.log("file fail"); console.log(error.message); } returns: Entry.fullPath: /readme.txt Entry.toURL(): filesystem: file:///temporary/readme.txt Which doesn't mean we shouldn't change our fullPath but I think we at least need to take other implementations into consideration.
        Hide
        Filip Maj added a comment -

        Added this to our API Audit article: http://wiki.apache.org/cordova/Core%20API%20Audit

        Show
        Filip Maj added a comment - Added this to our API Audit article: http://wiki.apache.org/cordova/Core%20API%20Audit
        Hide
        Filip Maj added a comment -

        Assigned to plugin media.

        Show
        Filip Maj added a comment - Assigned to plugin media.

          People

          • Assignee:
            Filip Maj
            Reporter:
            Dimitri Adamou
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development