Notification is displayed too late.

[Jakub Ś]

Steps to reproduce

1. Drop large file into editor e.g. 30MB image (large file size is used to increase time before notification is displayed)
2. Observe

Expected result

CKEditor should display notification once file is dropped.

It would be perfect if this was something like "Preparing file for upload" but from what I have talked with my colleague, it will be easier to just display "Upload 0%"

Actual result

CKEditor displays notification once it receives information about package size (file size with headers, control sums etc. which is greater than sole file size).

For few seconds there is no information and CKEditor is not responding. This can make users think that editor has hung and not that it is processing the file.

In fact CKEditor is processing base64 string for the image to preview it. For larger files we could intorduce configurable maximum file size for which preview should be shown. Any file size above that maximum will not be using preview. Reported here: #13825

Other details (browser, OS, CKEditor version, installed plugins)

This behaviour has been introduced in CKEditor 4.5.4. In CKEditor 4.5.3 we were using file size (smaller than whole package size) thus notification was displayed at once. In CKEditor we display real upload size but we get that information only after first progress event is fired.

[Jonathan]

Tracking

[Piotr Jasiun]

It is because of this ticket: #13533. We realized that the file size and the total size of the upload request are different (request contains additional information), so showing progress as uploaded data/file size can ends up with the progress bigger then 100%. We decided that we should use total upload request size. Unfortunately we do not know what is the total request size until we get the first response form server (progress event).

Additionally upload widgets use notification aggregator (​http://docs.ckeditor.com/#!/api/CKEDITOR.plugins.notificationAggregator) to aggregate all uploads into one notifications. You can add tasks with weights to it and change the information how big part of the task is done. Unfortunately, each task have a fixed weights and in this case weights is the size of the file.

So in the 4.5.4 ticket we decides to use total request size, but because of notification aggregator limitation we decided to add task after the first progress event, instead of the begging of the upload process (when we don't know the total size and can not change it later).

The solution would be adding possibility to change the total task size, setting it at the begging to the file size and changing later to the total request size. Alternatively, we could scale "done" part so it will be the percent of loaded data, but it would not should the correct information if user upload two files with different sizes.

[Szymon Kupś]

cc

[Tade0]

By examining the Notification Aggregator I noticed, that it contains a few private properties that store the sum of the total and done weights of all the tasks and are updated whenever the done weight of any task is updated.

This is redundant and since these values are only really used when getting the percentage I decided to dispose of them in favor of lazily calculating the percentage when it's necessary.

This way the requirement that the task should have a constant weight is relaxed.

I modified the uploadwidget so that now the task is created immediately and its total weight is updated as soon as it's possible.

Changes pushed to ​branch:t/13824.

[Marek Lewandowski]

Moving tickets to the next milestone.

[Marek Lewandowski]

Moving to 4.6.2 minor release, as 4.6.1 is mostly about polishing 4.6.0.