1339380 - <input type=date> should close selection popup when input loses focus

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[u424271]

Attachment: Screenshot showing issue

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

Comment 4

[Emilio Cobos Álvarez (:emilio)]

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

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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

[Mirko Brodesser (:mbrodesser-Igalia)]

Simple example to reproduce the issue:

1. Open data:text/html,<input type='date'> <input type="time">.
2. Click in the date field (pop-up appears).
3. 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

[Mirko Brodesser (:mbrodesser-Igalia)]

Rolling up popups seems to be managed by:

1. observing clicks in nsWindow::OnButtonPressEvent.
2. observing keystrokes in nsXULPopupManager::HandleKeyboardEventWithKeyCode.
3. 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?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(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:

https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/toolkit/content/widgets/datetimebox.js#579

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:

https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/toolkit/content/widgets/datetimebox.js#548

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.

Comment 11

[Mirko Brodesser (:mbrodesser-Igalia)]

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

[brentm]

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

[Kagami Rosylight [:saschanaz] (they/them)]

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.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Not really, the popup lives in the parent process iirc, it has no way to know what's focused on the child process.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1339380 - Close datetime picker when focus moves outside of our input element. r=mconley,gijs

This matches other browsers.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7daa0ef24433
Close datetime picker when focus moves outside of our input element. r=Gijs

Comment 18

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/7daa0ef24433