Bug 185086 – HTML5 File Picker Photo/Video Cancel does not send any event

• Status: NEW
• Component: Forms

[Doug Parker]

Reproducing code:

<input type="file" accept="image/*" capture="camera" />

const el = document.querySelector("input");
el.addEventListener("change", () => {
  alert("change");
});

Demo: http://output.jsbin.com/cuhihogugi

On iOS 11.3, opening the camera and then pressing cancel does not trigger the "change" event. That's probably reasonable, but in fact, it doesn't trigger ANY event that I am aware of. Not triggering "change" does make logical sense because, well, the file didn't change. However, there is no way for a web page to detect that a cancel event has happened. With a full-screen UI like this, such an event is necessary to know when the user has completed the camera flow so the app knows whether to wait for media. No other event is triggered to my knowledge which can be used for this purpose.

As an example, consider a UI which shows a camera and then redirects to show you your photo if you take one, or shows the error message "Please take a photo" if the user cancels. This simple UI is impossible because the site cannot know if/when the user pressed cancel! All it knows is that the "change" event has not yet triggered, but there's no way to know if the user is still in the camera and will soon take a photo, or has canceled out entirely.

Before 11.3, the common workaround was to listen to document.body.onfocus, as dismissing the camera implicitly refocused on the document and this works on Chrome 66 and prior. However this event is not triggered in 11.3. Of course this event is an implementation detail which I can't fault the browser for not triggering.

As far as I can tell, the spec leaves cancel behavior unspecified (https://www.w3.org/TR/html-media-capture/). This is really a bug in the spec, but it makes this API practically unusable for many mobile web applications. See https://stackoverflow.com/a/49785583/3995712 for the best workaround that I'm aware of which supports 11.3, which actually requires measuring CPU-cycles to infer if the app is running in the foreground or background.

I see two easy solutions to this:
1) Add a "cancel" event which triggers on cancel or a "done" event which triggers for cancel or change. This wouldn't break existing sites and would provide the necessary information to support this UI.
2) Trigger "change" on cancel. This is technically against spec, since the underlying file didn't actually "change". However, it is far easier for a JavaScript developer to dedup an extra change event, than to invent their own cancel event.

[Radar WebKit Bug Importer]

<rdar://problem/39821237>

[Geoffrey Garen]

Seems like we need a small spec change, such as an oncancel event.

I'd prefer oncancel to overloading onchange, since canceling the file selector is not, in literal fact, a file selection change.

[Theresa O'Connor]

I don't think a new event is necessary here. Instead of triggering your UI change when the user activates the control, wait to trigger the UI change when you receive the change event. That way, if the user cancels, your UI is not in a problematic state.

[Doug Parker]

Regarding comment 3, it is not always possible to wait for the change event to trigger the UI based on its design.

Consider a UI which requires a photo to proceed. The user can press a take photo button, but then if they cancel it makes sense to show an error message along the lines of: 'This app requires a photo to perform X action'. Such a simple UI like this is fundamentally impossible with the current API.

The "change" event also does not trigger immediately after the camera dismisses, there may be a couple seconds while the photo is processing. In this time, the user could press another button and break application logic by navigating to another screen for instance. The obvious fix for this would be to show a progress ring while taking the photo (which is what my particular app does), but the lack of a "cancel" event means that there is no way to know when the camera is dismissed and that it is safe to hide the progress ring and return to the previous screen.

[Doug Parker]

Filed a couple bugs against Chrome and the spec for this particular issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=883340
https://github.com/whatwg/html/issues/3976