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
@capacitor/camera does not honor users selection order #1950
Comments
Due to a race condition, pickImages on iOS did not honor the order in which users selected images. Fixes: ionic-team#1950
This issue needs more information before it can be addressed. Please see the Contributing Guide for how to create a Sample App. Thanks! |
Here's a very simple app to demonstrate the issue It shows a brief explanation on how to reproduce the issue and a button that, once pressed, allows you to select a bunch of images. Select some, let's say six or more, and keep in mind the order in which you selected them. Then tap the "done" button so that they are returned to the JS part of the application. After a couple of seconds you will see those images you selected rendered inside the Capacitor app. Take a look at them and you should see that they are not display in the same order you have picked them, even though there is no JS to explicitly shuffle them. Note: since this is caused by a race condition in the native iOS part of the If you take a look at the web app in your browser, you will see that the ordering of the picked images is preserved, no matter what. Here you can also find a video I recorded using the iOS Simulator that shows this application in action. Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-03-01.at.10.52.38.movChanges in associated PR (#1951) however, fix this issue by ensuring a consistent ordering |
@capacitor/camera does not honor users selection order
Plugin(s)
@capacitor/camera
Capacitor Version
Platform(s)
iOS
Current Behavior
Method
Camera.pickImages
exposed by the@capacitor/camera
plugin does not return image details using the same order in which users selected those images. Furthermore, selecting images over and over again, may yield different results each time (result of thepickImages
is not stable from a sorting point of view).In other words, if I have images 1 through 50,
Camera.pickImages
may return images in any arbitrary order. So, rolling with the same example as before, if I select images 1 through 50, I may get details about them in orders like:1,2,3,4,...49,50
(if I'm very lucky)2,1,3,4,7,10,5,....50,49
This is different from the behavior observed on Android where details about each image are returned using the same ordering in which user picked them. So, for example, in the first position of the array returned by the
pickImages
method, I'll find details about the firstly selected image. In the second position of that array, I'll find details of the second image selected by the user, and so on for each other image.Same thing goes for the underlying
<input type="file" multiple="multiple" />
we find in the web implementation of the@capacitor/camera
plugin.Expected Behavior
Expected result is that the order of selection is preserved, even when using the iOS implementation.
Additionally, selecting the same set of images multiple times, should yield to the same result.
Code Reproduction
If the above snippet uses the web or Android implementations of the
pickImages
method,photos
will be an array where each item is presented in the same order in which user selected images. If the above snippet uses the iOS implementation,photos
may have different orders. This is especially true and evident when selecting many images (with 30 images you are pretty much certain to encounter this problem).Additional Context
I did some debugging and it seems like the problem lies in the function
picker
defined in theCameraPlugin
extension (fileCameraPlugin.swift
).To be more precise, this problem boils down to a race condition in the handling of the result from
self?.processedImage
, where eachprocessedImage
is appended to an array in a closure of the asynchronous methodloadObject
.We've already developed a patch for this problem and we can confirm that this solved the problem our users encountered.
The text was updated successfully, but these errors were encountered: