The drop-down list cannot be opened
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: jsfsbrv, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: webcompat:platform-bug, webcompat:site-report, Whiteboard: [domcore-bugbash-triaged])
User Story
platform:windows,mac,linux,android impact:workflow-broken configuration:general affects:all branch:release user-impact-score:160 diagnosis-team:dom
Attachments
(4 files)
err.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
- On this page: https://sanjeobsoci.com/breakfast/?lang=en I want to book breakfast.
- I want to enter a reservation date.
- I select the drop-down list to select months
Actual results:
I want to change the reservation month. A drop-down list of months will open, but will close immediately. I can't pick a month.
Expected results:
The drop-down list must remain open until the user selects a month.
|
||
Comment 1•3 years ago
|
||
I can reproduce this as far back as 91, it seems to not be a recent regression.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 2•3 years ago
|
||
|
|
||
Comment 3•3 years ago
|
||
This page is doing some funky stuff with focus that I don't fully understand. Basically, the moment I click the month picker, focus is immediately stolen and document.activeElement becomes <body>. I can make the month picker appear by deactivating the focus handler with devtools.
This page seems to depend on the fact that stealing focus from user-initiated <select> is not possible in Chromium (I think?).
|
|
||
Comment 4•3 years ago
|
||
|
|
||
Updated•3 years ago
|
|
||
Comment 5•3 years ago
|
||
I did some investigate, after clicking the month select element, the page tried to focus the modal div element, and the focus moves to that element in Firefox, but in Chrome the modal div element isn't not focus-able. I think it is why we don't see this on Chrome.
<div id="myModal" class="modal fade in" role="dialog" style="display: block; padding-left: 0px;">...
|
|
||
Comment 6•3 years ago
|
||
(This is also related to bug 1334155 where we start hiding the drop-down list after the select element is blurred)
|
||
Comment 7•3 years ago
|
||
(In reply to Edgar Chen [:edgar] from comment #5)
I did some investigate, after clicking the month select element, the page tried to focus the modal div element, and the focus moves to that element in Firefox, but in Chrome the modal div element isn't not focus-able. I think it is why we don't see this on Chrome.
<div id="myModal" class="modal fade in" role="dialog" style="display: block; padding-left: 0px;">...
Hi Dennis, do you think we can reach out to the website to ask them to not rely on Chrome-specific behavior? Thanks.
|
||
Comment 8•3 years ago
|
||
I've sent them an email!
|
|
||
Updated•3 years ago
|
|
|
||
Updated•11 months ago
|
|
|
||
Updated•10 months ago
|
|
|
||
Comment 9•10 months ago
|
||
This is still broken, but the issue mentioned in comment 6 is marked as fixed. We should probably do another round of diagnosis here.
|
|
||
Comment 10•6 months ago
|
||
(I will take a look again)
|
|
||
Comment 11•6 months ago
|
||
(In reply to Edgar Chen [:edgar] from comment #5)
I did some investigate, after clicking the month select element, the page tried to focus the modal div element, and the focus moves to that element in Firefox, but in Chrome the modal div element isn't not focus-able. I think it is why we don't see this on Chrome.
<div id="myModal" class="modal fade in" role="dialog" style="display: block; padding-left: 0px;">...
This comment is no longer valid, on Chrome, the focus also moves to <div id="myModal" ...> when clicking the month select element.
|
|
||
Comment 12•6 months ago
|
||
As I mentioned in comment #6, the dropdown list closes because the <select> element loses focus. In contrast, both Chrome and Safari keep the dropdown open unless the focus moves to the browser UI. It seems like a long-existing behavior, and I didn't found any existing bug for this behavior, so I filed bug 1976341.
|
|
||
Comment 13•2 months ago
•
|
||
As chatted in the webcompat channel, I am removing the keyword webcompat:site-wait for this case. Other keywords reflect the recent situation more correctly.
Description
•