1800498 - Cannot change Departure/arrival dates in Google Maps on Android

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Dennis Schubert [:denschub]]

+++ This bug was initially created as a clone of Bug #1605611 +++

See the linked bug for details. We have an intervention for that, and it's likely that the intervention just needs a new selector, but it would be interesting to figure out

a) why this is breaking in the first place (i.e. why Firefox does get the disabled flag - that's not in Chrome afaict)
b) if Google can fix that.

We knew that there were some issues with input[type="datetime-local"] in the past, and the original report was depending on bug 1306217 - but that's now resolved. If we still see breakage, it might be something different that we probably should know about.

Comment 1

[Dennis Schubert [:denschub]]

Originally, there was an issue related to a <input type="datetime-local">s valueAsNumber attribute, which is why we shipped an intervention first. Ksenia diagnosed the issue and also built a testcase in bug 1583623. However, that issue is fixed these days, so this shouldn't cause any issues. In my tests, this looks like it's breaking due to UA sniffing on Google's end - and in fact, the button also has a disabled attribute in Chrome if I send a Firefox Android UA.

I just sent an email to Google folks. If they aren't able to fix that quickly, we can just revamp our intervention to fix this again, but I'll give them a couple of days. A proper solution on their end would be much better.

Comment 2

[Dennis Schubert [:denschub]]

A second, interesting, aspect is that in today's Nightly (and Nightly-only for now), after bug 1799565, we should be dispatching pointer events, even on a <button disabled>. Unfortunately this doesn't seem to fix this issue - the button still doesn't work. Unfortunately, it's not easy to debug this either, as the event dispatching in their frontend code is quite complex to probe from the outside...

Comment 3

[Thomas Wisniewski [:twisniewski]]

So this is pretty bizarre. They are setting disabled=true on the "leave now" button, which only seems to be done on Firefox. (Chrome doesn't even get the disabled attribute).

But that's not why it's broken. Indeed, pointerdown events are what it expects, according to the parent div's jsaction:

jsaction=`route_options_picker.chooseTime;pointerdown:route_options_picker.chooseTime;pointermove:route_options_picker.chooseTime;pointerup:route_options_picker.chooseTime;touchstart:route_options_picker.chooseTime;touchcancel:route_options_picker.chooseTime;touchmove:route_options_picker.chooseTime;touchend:route_options_picker.chooseTime`

And if I add my own pointerdown listener to the element, it does trigger when I tap on it despite the element being "disabled".

But it also works if I drop disabled, which implies that their own code is ignoring the event upon seeing it's disabled. And given that they use disabled=false elsewhere in the app to mark disabled-but-still-interactable inputs/buttons, them using true here would seem to imply this is a bug or intentional disabling.

Anyway, if I drop the disabled attribute, then the leave now popup works and I can test why the datetime-local isn't brought up. And it's for a completely different reason: it has z-index:-50000 on it to hide it under the edit/pencil icon. If I change that to opacity:0 then it works fine in Chrome and Firefox, and is still visually hidden.

So if there's an interop issue here, it's why Chrome allows clicking on a datetime-local despite it having z-index:-50000 (or maybe that's supposed to work, and Firefox is wrong here?)

I'll see if we can't add an intervention for this cycle, but it's a bit of a head-scratcher.

Comment 4

[Ksenia Berezina [:ksenia]]

Shipped in bug1805408