You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These paths were also returned by the `toURL()` method of the `Entry` objects.
424
426
425
-
With v1.0.0, the `fullPath` attribute is the path to the file, _relative to the root of
426
-
the HTML filesystem_. So, the above paths would now both be represented by a `FileEntry`
427
-
object with a `fullPath` of
427
+
Starting with v1.0.0, the `fullPath` attribute is the path to the file, _relative to the root of the HTML filesystem_. So, the above paths would now both be represented by a `FileEntry` object with a `fullPath` of
428
428
429
429
/path/to/file
430
430
@@ -433,23 +433,24 @@ paths through the `fullPath` property of `Entry` objects, then you should update
433
433
to use `entry.toURL()` instead.
434
434
435
435
For backwards compatibility, the `resolveLocalFileSystemURL()` method will accept a
436
-
device-absolute-path, and will return an `Entry` object corresponding to it, as long as that
437
-
file exists within either the `TEMPORARY` or `PERSISTENT` filesystems.
436
+
device-absolute-path, and will return an `Entry` object corresponding to it, as long as that file exists within either the `TEMPORARY` or `PERSISTENT` filesystems.
438
437
439
438
This has particularly been an issue with the File-Transfer plugin, which previously used
440
439
device-absolute-paths (and can still accept them). It has been updated to work correctly
441
-
with FileSystem URLs, so replacing `entry.fullPath` with `entry.toURL()` should resolve any
442
-
issues getting that plugin to work with files on the device.
440
+
with FileSystem URLs, so replacing `entry.fullPath` with `entry.toURL()` should resolve any issues getting that plugin to work with files on the device.
441
+
442
+
### v1.1.0
443
443
444
-
In v1.1.0 the return value of `toURL()` was changed (see [CB-6394](https://issues.apache.org/jira/browse/CB-6394))
445
-
to return an absolute 'file://' URL. wherever possible. To ensure a 'cdvfile:'-URL you can use `toInternalURL()` now.
446
-
This method will now return filesystem URLs of the form
444
+
Starting with v1.1.0, the return value of `toURL()` was changed (see [CB-6394](https://issues.apache.org/jira/browse/CB-6394))
445
+
to return an absolute 'file://' URL. wherever possible. To ensure a 'cdvfile:'-URL you can use `toInternalURL()` now. This method will now return filesystem URLs of the form
447
446
448
447
cdvfile://localhost/persistent/path/to/file
449
448
450
449
which can be used to identify the file uniquely.
451
450
452
-
In v7.0.0 the return value of `toURL()` for Android was updated to return the absolute `file://` URL when app content is served from the `file://` scheme.
451
+
### v7.0.0
452
+
453
+
Starting in v7.0.0 the return value of `toURL()` for Android was updated to return the absolute `file://` URL when app content is served from the `file://` scheme.
453
454
454
455
If app content is served from the `http(s)://` scheme, a `cdvfile` formatted URL will be returned instead. The `cdvfile` formatted URL is created from the internal method `toInternalURL()`.
455
456
@@ -461,6 +462,13 @@ An example `toInternalURL()` return filesystem URL:
461
462
462
463
It is recommended to always use the `toURL()` to ensure that the correct URL is returned.
463
464
465
+
### v8.0.0
466
+
467
+
Starting in v8.0.0 the return value of `.toURL()` was changed for iOS to bring
468
+
the behaviour more closely to Android. If the webview is hosted on `file://` scheme,
469
+
then `.toURL` return will not change and will continue to return a `file://` URI.
0 commit comments