Uploading images in order of filename

OS not web browser

I’d say it is not the web browser because the APIs used by most programs generally end up using the APIs provided by the OS.

It is easy enough to check because the web browser will be using a Web API (e.g. Firefox Web API for file selection) that is different to the API used in other applications (e.g. Microsoft Word). A programmer with the inclination could create a Javascript routine to test file selection in both applications which run Javascript.

I just did it by selecting images to upload in Firefox and to insert in Microsoft Word - all in WIndows 10. The file selection behaviour is the same in both.

File selection behaviour is unusual but not the complete problem

The files are selected in such a way that the last file selected always appears first in the file list so you only have to look at the start of the list to check which file is currently being selected.

  1. “file 1”
  2. “file 2” “file 1”
  3. “file 3” “file 1” “file 2”
  4. “file 4” “file 1” “file 2” “file 3”

As long as the files are selected in the same order then the list of files looks the same whether I use shift to select a list or ctrl to select each file individually or a combination of both.

It could have been done differently but I like seeing the last file selected at the start of the list because it means less eye movement for me. However this has two problems:

  • It is counter-intuitive not to see the last file selected at the end of the list.
  • That list sequence is probably not what is used to provide the sort order in Discourse despite what we’ve been told.

I’m happy to be proved wrong.

Display order in Discourse appears to be based on something like upload completion times

The file order appears to be based on the sequence of completed uploads. It didn’t matter how many ways I selected the files, the order on Discourse was usually different. This is a common problem on many other sites and networks (e.g. print spooling) where upload completion sequence determine the storage and display order.

Here’s examples of what I got on Discourse for image files originally created in a time sequence from 1 to 4.

Selected individually in reverse order
Run 1
2 4 1 3
Run 2
3 2 4 1

Selected as a group in reverse order
Run 1
3 2 1 4
Run 2
1 4 3 2

P.S.
The file size sequence is 1, 4, 2, 3 from smallest to largest. Interestingly enough that is the reverse of what appears to be the most likely base sequence above 3, 2, 4, 1.

The file data by date and time is as follows:
20/08/2018 08:50 PM 550 1.png
20/08/2018 08:51 PM 697 2.png
20/08/2018 08:51 PM 809 3.png
20/08/2018 08:51 PM 600 4.png

P.P.S. Yes, I know that I shouldn’t have used the reverse sequence - it just complicates this. I only did that because someone suggested that would be a solution to the problem.

2 Likes

I’m so close to the servers, and I used very small images. It is possible that order of upload completion could be a factor as well… you could test this by uploading one very large image and 3 small ones in a single batch.

It definitely looks like upload completion time primarily determines the sequence:

  • The tiny images appear first although in somewhat random order
  • The largest file had the earliest date but appears last because it is largest.
  • The second largest file appears second to last although it was the sixth file by date.

20/08/2018 08:51 PM 809 3.png

3

20/08/2018 08:51 PM 697 2.png

2

20/08/2018 08:51 PM 600 4.png

4

20/08/2018 08:51 PM 738 5.png

5

20/08/2018 08:50 PM 550 1.png

1

20/08/2018 11:51 PM 769 7.png

7

6 - 20/08/2018 11:52 PM 7,596,756 6.png

0 - 10/10/2013 06:18 PM 9,106,055 0.jpg

2 Likes

Oh yeah, that is definitely a bug/feature request.

Our image placeholders have no sequence so ordering is indeed random depending on the replies we get back from the server.

We need to redo our placeholders so they also have a sequence number in them.

5 Likes

Thanks for the extensive testing @Remah :mask:

4 Likes

Are you saying you could alter the order attachments are inserted into a post in a future update? If so, that would be fantastic.

Yes I am saying instead of rendering:

[Uploading...]() 
[Uploading...]() 
[Uploading...]() 

We will render:

[Uploading... (1)]() 
[Uploading... (2)]() 
[Uploading... (3)]() 

(Single uploads will still be: [Uploading...]() for aesthetic reasons.)

Then when we get the replies back from the server with the actual location of the upload we can correctly associate with the right upload.

We have spent so much time debugging this now, its worth just getting the fix int.

@maja can you add this to your list, not high priority.

4 Likes

You will need a way to “tag” an upload with its sequence number (after sorting by filename if possible) in the client and keep that “tag” on the server so it’s sent back to the client once the upload is fully processed.

3 Likes

Note we hijack on upload so the same request that POSTs the upload can take care of this, if the jquery uploader thing has all the right hooks then we may get away without needing any server level changes.

3 Likes

To be clear YOU WILL STILL GET UPLOADS IN THE EXACT ORDER THAT YOUR OPERATING SYSTEM SENDS THEM.

With this change, you’ll just be sure that they aren’t affected by upload speeds, and the smallest images arriving first… that’s all :hugs:

4 Likes

This has been fixed in

https://github.com/discourse/discourse/pull/6306

5 Likes