mirror of
https://github.com/bulwarkmail/webmail.git
synced 2026-10-31 00:12:39 +00:00
Roman Varlakov
7928f72ee2
The composer chip only knew a boolean: `uploading` flipped on, an indeterminate bar animated at 40% width, and nothing anywhere carried a percentage, so a large attachment on a slow link looked frozen for the whole transfer. The JMAP client has been able to report real progress since #333 gave uploadBlob an XHR path with onProgress; the composer just never passed it. Stock path: pass onProgress and the existing AbortController's signal to client.uploadBlob. The chip's bar becomes determinate as soon as bytes are reported (falling back to the indeterminate animation otherwise), and cancel now aborts the transfer itself instead of being checked only once the upload has finished. Plugin offload path (#751): a plugin that offloads an attachment moves the bytes itself via api.http.post, which the composer cannot observe. It also cannot be handed a callback: the sandbox bridge marshals functions host-to-plugin only, and the File a plugin holds is a structured clone, so object identity cannot correlate its request back to an attachment. The staged file id can: the composer generated it and handed it to onBeforeBlobUpload. A plugin echoes it back as the new optional `progressFileId` on the post options; the host sends the Blob via XMLHttpRequest (fetch exposes no upload progress events) and reports bytes into a host-side registry keyed by that id, which the composer subscribes to before running the hook. Progress never crosses into the sandbox, and reports for an id the composer is not tracking are dropped, so the plugin API grows exactly one optional field. Calls without progressFileId keep the fetch path untouched. Closes #754
51 lines
1.7 KiB
TypeScript
51 lines
1.7 KiB
TypeScript
import { describe, it, expect, vi } from 'vitest';
|
|
import { onUploadProgress, reportUploadProgress } from '../upload-progress';
|
|
|
|
describe('upload progress registry', () => {
|
|
it('delivers reports to the listener registered for the id', () => {
|
|
const listener = vi.fn();
|
|
const off = onUploadProgress('file-1', listener);
|
|
reportUploadProgress('file-1', 512, 2048);
|
|
expect(listener).toHaveBeenCalledWith(512, 2048);
|
|
off();
|
|
});
|
|
|
|
it('drops reports for an id nobody listens to', () => {
|
|
const listener = vi.fn();
|
|
const off = onUploadProgress('file-1', listener);
|
|
reportUploadProgress('file-2', 1, 2);
|
|
expect(listener).not.toHaveBeenCalled();
|
|
off();
|
|
});
|
|
|
|
it('stops delivering after unsubscribe', () => {
|
|
const listener = vi.fn();
|
|
const off = onUploadProgress('file-1', listener);
|
|
off();
|
|
reportUploadProgress('file-1', 1, 2);
|
|
expect(listener).not.toHaveBeenCalled();
|
|
});
|
|
|
|
it('ignores non-finite byte counts', () => {
|
|
const listener = vi.fn();
|
|
const off = onUploadProgress('file-1', listener);
|
|
reportUploadProgress('file-1', NaN, 100);
|
|
reportUploadProgress('file-1', 50, Infinity);
|
|
expect(listener).not.toHaveBeenCalled();
|
|
off();
|
|
});
|
|
|
|
it("unsubscribing a stale registration does not drop the id's current listener", () => {
|
|
const first = vi.fn();
|
|
const second = vi.fn();
|
|
const offFirst = onUploadProgress('file-1', first);
|
|
const offSecond = onUploadProgress('file-1', second);
|
|
// The composer re-registered the id; the stale unsubscribe must be a no-op.
|
|
offFirst();
|
|
reportUploadProgress('file-1', 10, 100);
|
|
expect(second).toHaveBeenCalledWith(10, 100);
|
|
expect(first).not.toHaveBeenCalled();
|
|
offSecond();
|
|
});
|
|
});
|