Form element taking focus from USB pairing dialog. |
|||||
Issue descriptionChrome Version : 67.0.3396.62 OS Version: OS X 10.13.4 URLs (if applicable) : What steps will reproduce the problem? Attempt to pair a WebUSB device from the click handler of a <button> inside a <form>. What is the expected result? A device pairing dialog box appears allowing the user to select a USB device. What happens instead of that? The <form> element takes focus away from the pairing dialog box. The result is that the pairing dialog box flashes on screen for a fraction of a second then vanishes. Please provide any additional information below. Attach a screenshot if possible. Here's a link to my code. https://github.com/jpmedley/web-experiments/tree/form-bug/usb It has <button> elements both inside and outside of a <form> element. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36 One of the Chrome developers tells me he's not sure if what I'm seeing is actually a bug since he doesn't know what the expected focus behavior for a form is. I would argue that if the current focus behavior complies with requirements then the requirements should change. Consider that <button> elements are permitted as children of <form> elements according to the HTML spec. If the spec won't work unless I change my markup away from what the spec says in permitted, then it feels like I'm hacking around a bug whether that's true or not.
,
May 30 2018
Here's a live version of my code. https://jpmedley.github.io/web-experiments/usb/?
,
May 30 2018
I will do an initial investigation of this behavior.
,
May 30 2018
I've tried this on Chrome OS, Linux, macOS and Windows and this appears to only reproduce on macOS.
,
May 31 2018
On macOS the dialog is being closed because the ChromeBubbleManager detects that a cross-document navigation has occurred. It appears that this navigation is not happening on other platforms. Since the <button> is not the form's submit button it is strange that this is triggering a navigation.
,
May 31 2018
It appears that <button> is type=submit by default so that explains why it is causing a navigation when clicked. Moving this into the Blink>Forms>Button component because the USB chooser code is working as intended. I will follow up with an investigation of why the behavior appears to be different on other platforms. Perhaps someone who owns this component can beat me to it.
,
May 31 2018
Just to clarify things for whomever gets this (and to satisfy my own curiosity) I've added a third case to may code. There is now a button in my form that has it's type set to button.
,
May 31 2018
This is odd. On your updated site with the three different buttons the one with the default type automatically closes the dialog as expected on Windows and Chrome OS. Can you restore this to the previous version which displayed the inconsistent behavior? That is what I'm planning to investigate.
,
Jun 1 2018
Is this reproducible with <a href="https://jpmedley.github.io/web-experiments/usb/"> and addEventListener('click', usb....) for the <a>? I don't think this is an issue of Blink>Forms>Button. Probably, an issue of dialog window implementation.
,
Jun 27 2018
This is working as intended. On navigation the USB device chooser is closed. A <button type=submit> (which is the default) in a <form> element will cause a navigation when clicked. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jmedley@chromium.org
, May 30 2018