| Stryn | |
| Dec 23 2017, 12:48 PM |
| F12010686: phab1.jpg | |
| Dec 23 2017, 12:48 PM |
| F12010695: phab3.jpg | |
| Dec 23 2017, 12:48 PM |
When you go to user contributions page and want to select some dates from the form, you should not click the form too quickly or you will see a wrong calendar which is provided by the browser. In Firefox both calendars will then show at the same time. In Edge the wrong one is closed automatically before the Wikimedia versioned calendar opens,
See Firefox:
See Edge:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| mw.special.contributions: Do not infuse the date input while it has user focus | mediawiki/core | master | +33 -7 |
Yes, I can reproduce this.
Also, the placeholder initially shows stuff like "mm / dd / yyyy" before it changes to "No date selected" when resources/src/mediawiki.widgets/mw.widgets.DateInputWidget.js has finally been loaded.
This sounds like a browser bug. When we add our own calendar, we change the type of the field from date to text, so the browser should probably close its own calendar when that happens. I wonder if we could force it to be closed…
@matmarex I don't think the browser bug covers the entirety of this UX problem (the user's interaction would be cut off essentially), but it would be good as a first step.
Once the browser bug is fixed (or worked around), we should still see if there's a better way to ensure an uninterrupted UX.
If this is specific to Firefox, do we have an upstream bug?
I fiddled with this a little today and it seems that in Firefox, there is actually no way for us to close the "native" browser popup! It is not closed when the input is blurred, not closed when changing 'type' attribute, not closed when hiding the input with 'display: none', and not closed even if you remove the node with .removeChild().
Some test cases: https://jsfiddle.net/a3kuwm3a/ https://jsfiddle.net/vqk6g9u6/
Relevant upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1339380 "<input type=date> should close selection popup when input loses focus".
I think to avoid this, we'll just have to wait for the user to stop working with the input, if they already focussed it before the page finished loading, before we replace it with our fancy version. This might end up in inconsistent experience (sometimes you get the native date picker, sometimes the fancy one), but still better than the current broken state. One downside to this is that we'll need to implement this separately everywhere we use a DateInputWidget…
Change 428145 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] mw.special.contributions: Do not infuse the date input while it has user focus
Change 428145 merged by jenkins-bot:
[mediawiki/core@master] mw.special.contributions: Do not infuse the date input while it has user focus