Provide open/close events (or equivalent) for dialog popups, such as <input type=file>

[ghost]

Currently as it stands, there is nothing in the HTML5 Media Capture spec which communicates to the page that the user canceled the capture. This makes UI development very difficult because the file picker may or may not trigger a change event at an unbounded time in the future. As an example, consider the following use case:

I have a site which requires the user to provide a photo to continue. The user presses a button to open the file picker. Once they capture a photo we progress to the next screen and do something with the photo. However, if the user presses cancel, it can be useful to show a dialog which says "Hey, we need photo for these reasons and can't proceed without one." before re-opening the file picker.

This UI is impossible in the current spec, because no cancel event is defined. There would be no way to know when the user canceled the picker and the UI needs to designed so that it does not require this information.

The change event may trigger if there was already a photo/video on the file picker. However, if the file picker currently has no content, and then the user cancels, there is no observable event that it triggers.

On Chrome today you can listen for document.onfocus and this used to work in Safari but no longer does after a recent update. However, these are only workarounds for a flawed API, which I would love to see improved.

Media Capture Spec
WebKit bug
StackOverflow

[zcorpan]

Is this an issue with the HTML standard or the Media Capture spec?

Issues for the Media Capture spec should be filed here: https://github.com/w3c/html-media-capture/issues/

[tkent-google]

I think this is an issue of <input type=file> UI, not specific to Media Capture.

Also, this is common in form controls with popup UI. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25452

[annevk]

(See also #1102.)

[ghost]

@zcorpan I was specifically thinking of the Media Capture spec, but I think this change could easily apply outside of Media Capture. I think it would be perfectly reasonable even on desktop with a generic file picker to trigger a "cancel" event which the page can react to.

[ghost]

Filed a Chrome bug about this issue as well: https://bugs.chromium.org/p/chromium/issues/detail?id=883340

[MatsPalmgren]

I have a site which requires the user to provide a photo to continue. The user presses a button to open the file picker. Once they capture a photo we progress to the next screen and do something with the photo. However, if the user presses cancel, it can be useful to show a dialog which says "Hey, we need photo for these reasons and can't proceed without one." before re-opening the file picker.

Fwiw, forcing the user to click through modal dialogs like that feels a bit old-school UI to me. I tend to think that modal dialogs are best avoided in general.

Anyway, HTML+CSS already supports all sorts of validity states - aren't those sufficient for this use case? e.g.

<style>
input:invalid ~ div::after {
  display: block;
  content: "(photo required)";
  color: red;
}
</style>
<input type=file required>
<div></div>

Using events + JS for this is brittle - what about NoScript users? what if my UA supports drag-n-drop of files directly onto the element without opening the file dialog at all - did your script account for that case? etc.
It seems better to use pure HTML+CSS for this use case IMO.

[ghost]

Fwiw, forcing the user to click through modal dialogs like that feels a bit old-school UI to me. I tend to think that modal dialogs are best avoided in general.

I can agree in general, but not all designs have that luxury. My primary motivation for this was to require a photo from the Media Capture API. This triggers the camera to open full-screen and I have no means of requiring that the user take a photo to continue. They can always hit cancel and I need to give some kind of error indication. In our UI, an error dialog is the best way of representing that.

Anyway, HTML+CSS already supports all sorts of validity states - aren't those sufficient for this use case?

The example in my original comment is a simplistic version of the real problem we've faced. In reality, we're a single page Polymer application. When the user presses a particular button, we trigger the file picker to capture a photo. We then perform some processing, allow the user to edit some things, and eventually upload the photo. That requires a pretty significant amount of JavaScript logic to support.

Beyond this, capturing a photo is only one action a user can take, it's only one UI path. This isn't a web form with a required photo field which then performs a form submission to another URL. Using only HTML+CSS can work for some sites supporting certain use cases, however our's is not one of them.

Using events + JS for this is brittle - what about NoScript users?

We're a single page Polymer application with highly dynamic, user-created, content. We don't support NoScript users because it would be fundamentally impossible to provide anything close to our PWA's experience without JavaScript. NoScript users should definitely be supported by sites which are able to, but we do not fall into that category and relying on JavaScript here is not a concern for our use case.

what if my UA supports drag-n-drop of files directly onto the element without opening the file dialog at all - did your script account for that case?

We're a purely mobile app, so I'm not even sure if that's possible from a mobile device. It's certainly not a highway use case for sure. Regardless, our UI renders this particular button within a floating action button, so the user really can't drag-and-drop onto it. In our case, it would actually make sense to allow the user to drag and drop onto the entire screen, not a particular file <input /> element. We can easily add an ondrop handler to support that use case and provide a much better experience than the default functionality would. Yes it would take a little more work and we don't get it "for free", but its a trade off we would be willing to make.

In summary:

The HTML+CSS option is great for the reasons you mentioned, but it doesn't work for all use cases. Highly dynamic JavaScript apps like ours are just one example where it comes up short. Adding a "cancel" or "close" JavaScript event simply provides another option for sites which can benefit from it. There is already a "change" event for use cases like ours, I'm simply advocating for expanding that support to other useful events like "cancel" or "close".

[plinss]

@MatsPalmgren there are plenty of other use cases for this, a quick google search will find a lot of people looking for a solution here that isn't solved by CSS. Most are using the hack of detecting that the focus reverts to the document, but this behavior isn't clearly specified and is not interoperable.

I have a concrete use case myself: I'm developing an app that has photo blogging capability, the user clicks a button to post a photo and is taken to the photo posting page. The page then immediately launches a modal camera UI on top of itself allowing the user to take a photo in the app. If they click the camera's cancel button it closes the camera, but also closes the underlying photo posting page. In the case where the user has denied camera access, the page opens a file picker dialog instead, allowing the user to select a photo from the photo roll (on mobile) or their local file system (the photo posting page is shown underneath for UI context). If they cancel the file picker, I want to have the same experience of closing the photo posting page as well. Currently there's no way to reliably detect the cancel and do this. An event is fired when the user picks a file, why not an event when they cancel?

[ghost]

I just realized that this bug was filed while our PWA was still in limited accessibility. We've since opened it up for public use so you can just look at it (you must be on a mobile user-agent to access it, either use a mobile phone or emulate it in Chrome): https://posts.google.com/bulletin/app/

Quick one-sentence explanation of our product: We're a new Google product called Bulletin which allows users to capture text/photos/videos about events in their local communities and post them publicly to the Internet.

Feel free to make an account and play with the app. Under the floating action "Start Story" button we use a file picker for "Choose existing" and also HTML5 Media Capture for "Take photo" and "Take video". We do prefer WebRTC if that is supported. You can use an iOS device to see Media Capture in action.

We have since refactored a lot of the logic so as not to rely on a file picker "cancel" event, since it doesn't exist. That refactor took a non-trivial amount of effort and requires us to split our logic, one set for WebRTC photos/videos and another for HTML Media Capture photos/videos even though much of the same processing is done on them. The UI probably feels reasonable to a user, but it would be significantly easier to implement if we had the luxury of a "cancel" event.

[annevk]

This got fixed. Duplicating this into #6376.