Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a "cancel" event for when file upload selection is unchanged #6735

Merged
merged 3 commits into from
Jul 8, 2021
Merged

Add a "cancel" event for when file upload selection is unchanged #6735

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3c37dfb
Add a "cancel" event for when file upload selection is unchanged
domenic Jun 3, 2021
6989420
Review comments
domenic Jun 17, 2021
5b15293
Review feedback
domenic Jul 8, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 28 additions & 10 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47817,11 +47817,11 @@ ldh-str = &lt; as defined in <a href="https://tools.ietf.org/html/rfc1034#
no more than one file in the list of <span data-x="concept-input-type-file-selected">selected
files</span>.</p>

<p>The element's <span>input activation behavior</span> is to run the following steps:</p>
<p>The <span>input activation behavior</span> for such an element <var>element</var> is:</p>

<ol>
<li><p>If the algorithm is invoked when the element's <code>Window</code> object does not have
<span>transient activation</span>, then return without doing anything else.</p></li>
<li><p>If the algorithm is invoked when <var>element</var>'s <span>relevant global object</span>
does not have <span>transient activation</span>, then return.</p></li>

<li>
<p>Run these steps <span>in parallel</span>:</p>
Expand All @@ -47830,15 +47830,33 @@ ldh-str = &lt; as defined in <a href="https://tools.ietf.org/html/rfc1034#
<li><p>Optionally, wait until any prior execution of this algorithm has terminated.</p></li>

<li><p>Display a prompt to the user requesting that the user specify some files. If the <code
data-x="attr-input-multiple">multiple</code> attribute is not set, there must be no more than
one file selected; otherwise, any number may be selected. Files can be from the filesystem or
created on the fly, e.g., a picture taken from a camera connected to the user's
device.</p></li>
data-x="attr-input-multiple">multiple</code> attribute is not set on <var>element</var>, there
must be no more than one file selected; otherwise, any number may be selected. Files can be
from the filesystem or created on the fly, e.g., a picture taken from a camera connected to the
user's device.</p></li>

<li><p>Wait for the user to have made their selection.</p></li>

<li><p><span>Update the file selection</span> for the <code>input</code> element.</p></li>
<li><p>If the user dismissed the prompt without changing their selection, then <span>queue an
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to be more specific here? As written, this would fire "cancel" if a user selected a file, clicked OK, re-opened the file picker, selected the same file again, and clicked OK. In that case, the selection "would not be changed". Is that intentional? If so, perhaps this case could be explicitly folded into the new note below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that's right. Such a case would fire "cancel" and not "change", since nothing changed. I'll add it to the example.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, well, it kind of depends; something might have changed, since maybe the files changed on disk? But I don't think the event should need to branch on that.

So I guess now I'm thinking it's up to the UA. As long as it picks one of the two events it's OK. I'll try to come up with some phrasing...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this a bit more, I'm thinking the more correct thing would be to fire change in this case (re-selecting the same file). The issue is that otherwise, a developer would have no way to detect this situation. There are two possibilities:

  1. Re-selection triggers cancel: There is no way to disambiguate re-selection from hitting cancel.
  2. Re-selection triggers change: The developer can, if they like, store the previously-selected file, and compare them upon receipt of change.

It seems plausible that a developer might want to do something different when the user clicks "ok" vs "cancel".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that's up to the UA. It seems like a valid user interface to say that if the user didn't change anything (i.e. re-selected the same files), then that shouldn't be distinguishable from hitting cancel.

element task</span> on the <span>user interaction task source</span> given <var>element</var>
to <span data-x="concept-event-fire">fire an event</span> named <code
data-x="event-cancel">cancel</code> at <var>element</var>, with the <code
data-x="dom-Event-bubbles">bubbles</code> attribute initialized to true.</p></li>

<li><p>Otherwise, <span>update the file selection</span> for <var>element</var>.</p></li>
</ol>

<p class="note">As with all user interface specifications, user agents have a good deal of
freedom in how they interpret these requirements. The above text implies that a user either
dismisses the prompt or changes their selection; exactly one of these will be true. But the
mapping of these possibilities to specific user interface elements is not mandated by the
standard. For example, a user agent might interpret clicking the "Cancel" button when files were
previously selected as a change of selection to select zero files, thus firing <code
data-x="event-input">input</code> and <code data-x="event-change">change</code>. Or it might
interpret such a click as a dismissal that leaves the selection unchanged, thus firing <code
domenic marked this conversation as resolved.
Show resolved Hide resolved
data-x="event-cancel">cancel</code>. Similarly, it's up to the user agent whether re-selecting
the same files counts as were previously selected counts as a dismissal, or as a change of
selection.</p>
</li>
</ol>

Expand Down Expand Up @@ -123468,8 +123486,8 @@ INSERT INTERFACES HERE
<tr> <!-- cancel -->
<td> <dfn event for="HTMLElement"><code data-x="event-cancel">cancel</code></dfn>
domenic marked this conversation as resolved.
Show resolved Hide resolved
<td> <code>Event</code>
<td> <code>dialog</code> elements
<td> Fired at <code>dialog</code> elements when they are canceled by the user (e.g. by pressing the Escape key)
<td> <code>dialog</code> elements, <code>input</code> elements
<td> Fired at <code>dialog</code> elements when they are canceled by the user (e.g., by pressing the Escape key), or at <code>input</code> elements in the <span data-x="attr-input-type-file">File</span> state when the user does not change their selection

<tr> <!-- change -->
<td> <dfn event for="HTMLElement"><code data-x="event-change" id="event-input-change">change</code></dfn>
Expand Down