<input type=date> should close selection popup when input loses focus
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox84 | --- | fixed |
People
(Reporter: u424271, Assigned: emilio)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
STR 1 Open Nightly with blank profile 2 Open about:config and set: dom.forms.datetime = true dom.forms.datetime.timepicker = true 3 Open webpage with a <input type='date'> field 4 Click in input field (date picker should open) 5 Press tab key until input loses focus AB Date picker selection popup stayed open EB Date picker selection popup should have been closed
![]() |
||
Updated•8 years ago
|
Updated•8 years ago
|
Updated•7 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
Hsin-Yi, do you think anyone from the DOM team could work on this? This is mostly DOM code in the datetimebox widget, and this is one of the issues with more dupes about them.
I could try to find some time on my own to do this, but I also need to do other stuff :)
Comment 5•6 years ago
|
||
(In reply to Emilio Cobos Γlvarez (:emilio) from comment #4)
Hsin-Yi, do you think anyone from the DOM team could work on this? This is mostly DOM code in the datetimebox widget, and this is one of the issues with more dupes about them.
Yes, Mirko has been helping with related issues. :)
Thank you Emilio!
I could try to find some time on my own to do this, but I also need to do other stuff :)
Comment 6•6 years ago
•
|
||
Simple example to reproduce the issue:
- Open
data:text/html,<input type='date'> <input type="time">
. - Click in the date field (pop-up appears).
- Tab to the other input field (pop-up doesn't disappear).
It reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1210253, but not sure if it's related.
Comment 7•6 years ago
|
||
Rolling up popups seems to be managed by:
- observing clicks in nsWindow::OnButtonPressEvent.
- observing keystrokes in nsXULPopupManager::HandleKeyboardEventWithKeyCode.
- other calls to nsXULPopupManager::HidePopup which don't show any direct relation to DOM events. However, there might be an indirect relation I haven't discovered yet.
One possible fix for this issue could be to adapt nsXULPopupManager::HandleKeyboardEventWithKeyCode to also hide the popup when the "tab" key is pressed. However, I can't tell if this breaks other functionality and it seems to be an inelegant solution.
Perhaps a more elegant solution is to somehow connect the parent of the popup (assuming that's the <input type="date">
-- I don't know the implementation details) element to its blur event. On blur, notify the popup to be closed.
Emilio, any thoughts about this?
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Mirko Brodesser from comment #7)
One possible fix for this issue could be to adapt nsXULPopupManager::HandleKeyboardEventWithKeyCode to also hide the popup when the "tab" key is pressed. However, I can't tell if this breaks other functionality and it seems to be an inelegant solution.
Yeah, that's probably not the way to go, you want to keep the picker open while tabbing through the inner fields in the datetime box.
Perhaps a more elegant solution is to somehow connect the parent of the popup (assuming that's the
<input type="date">
-- I don't know the implementation details) element to its blur event. On blur, notify the popup to be closed.Emilio, any thoughts about this?
Yes, the popup state is controlled in the datetimebox widget, see this for example:
I think just doing something like:
if (this.mIsPickerOpen) {
this.mInputElement.closeDateTimePicker();
}
In the onBlur
handler a couple lines above should do it, but I think it may need to be a little more subtle, since I don't see anything that would prevent us closing the picker when moving the focus inside the datetime input itself.
So maybe if (this.mInputElement != document.activeElement && this.mIsPickerOpen)
is the right condition there, if the new active element is already updated by the time blur fires. Or maybe this is the right place otherwise:
Not sure, would have to test. But yeah, the change to fix this bug should probably be in datetimebox.js rather than native code, I suspect.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
As I haven't found the time to work on this bug and expect to not have it in the near future, I'll remove the NI request I added myself. If I find time to work on it, I'll assign it to myself.
Comment 12•4 years ago
|
||
Is there any chance this can be looked at again? When using a browser for data entry, most of my users will use the keyboard to tab into and type a date, and then tab into the next field. However the open datepicker obstructs the view of the next field, making the user have to use the mouse (to click on a random location within the page in order to close the picker), and slowing down the time to fill the form. For those who use their browsers for data entry, this is driving some of my users away from Firefox, which is very sad, as I have hitherto used what influence I have to encourage use of Firefox.
Comment 14•4 years ago
|
||
What closes the widget when I click the outside of it? It seems a popuphidden
event is fired from somewhere but I couldn't confirm where it is from. Calling the close function inside onblur listener as comment #8 said should work, but it seems this could be done in the widget system to be more general.
Assignee | ||
Comment 15•4 years ago
|
||
Not really, the popup lives in the parent process iirc, it has no way to know what's focused on the child process.
Assignee | ||
Updated•4 years ago
|
Comment 17•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7daa0ef24433 Close datetime picker when focus moves outside of our input element. r=Gijs
Comment 18•4 years ago
|
||
bugherder |
Description
•