Closed Bug 1605611 Opened 3 months ago Closed 2 months ago

Cannot change Departure/arrival dates in Google Maps on Android

Categories

(Web Compatibility :: Mobile, defect)

Unspecified
Android
defect
Not set

Tracking

(firefox-esr68 fixed)

RESOLVED FIXED
Tracking Status
firefox-esr68 --- fixed

People

(Reporter: robwu, Assigned: robwu)

References

()

Details

See https://github.com/webcompat/web-bugs/issues/39281

This is not a new issue, I have encountered this issue early this year, and someone else complained about this to me today.

I have created a prototype of an intervention, and will turn it into an intervention and submit a patch to the webcompat-addon repo.

The issue is caused by the following issues:

  1. Google Maps uses UA sniffing, and adds the "disabled" attribute to the "Leave now" button.
  2. Google Maps assigns the current date at a seconds precision via dateAsNumber, but Firefox treats the input as invalid because the input only accepts a precision of minutes (due to the default value of 60 for the "step" attribute). This was also reported as bug 1583623 (unresolved).
  3. Google Maps uses .click() on the datetime-local input, expecting it to show the native UI. This doesn't work because the native input UI is only shown when the user initiates the click.

I've resolved the above problems by:

  1. Removing the "disabled" attribute from the .ml-directions-time element.
  2. Ensuring that all datetime-local elements are only assigned timestamps at a precision level of one minute.
  3. Render the actual datetime-local input on top of the relevant part of the maps UI, at 0 opacity to allow the user to summon the native UI without a negative impact on appearance.

This only affects the mobile version of Google Maps; on desktop Google Maps has a different UI. And on desktop, the datetime-local input element is not even supported (the input can be enabled by setting dom.forms.datetime.others to true, but that does not trigger a separate datepicker modal).

When will m-c be updated with code from Github?
I'm very confused by the diverged state of the Github repo and m-c. I would expect a separate Bugzilla issue to track the next release (e.g. as seen in bug 1587558 for the previous release), but the 7.0.0 commit on Github is associated with an old, already-closed Bugzilla issue.

According to the Github commit history, you've imported various patches from Phabricator and bumped the version to 7.0.0 (https://github.com/mozilla/webcompat-addon/commit/bd04bb787fdc3d531bcf248d23522b9b7ff59c5a).
On m-c, the patches from Phabricator are included, but neither my patch here, nor the version bump is included.

This is especially relevant because my patch here uses a method that someone is/was going to remove in bug 1607525 / https://phabricator.services.mozilla.com/D59064 .
My patch is on Github, the patch for bug 1607525 is on m-c. In their own branches, any tests would pass tests.
But when merged, the webcompat add-on would fail to initialize because my patch uses a function that bug 1607525 wanted to remove.

Flags: needinfo?(dschubert)

When will m-c be updated with code from Github?

At the end of the current release cycle, likely in the week before soft freeze. Unless we have an emergency, that is. Check our release documentation on WikiMo, especially the "Release Process" section, if you want to learn more.

I would expect a separate Bugzilla issue to track the next release

With the newly created regular merge process, there is no need for that. These bugs are created on-demand to land something, but not in preparation for the cycle. The only cases where we create a bug ahead of time is in case of emergency, i.e. fixing a regression that's tracked by RelMan, fixing a high-profile site, or anything else that requires system addon update rollouts outside of the tree.

but the 7.0.0 commit on Github is associated with an old, already-closed Bugzilla issue

The fact that I had to bump the version number after a change was an oversight. I conditionally r+'ed on the bug asking for the version number to be bumped, but because everyone was in a hurry, that comment was missed. I disappeared for vacation the same day, and yesterday was my first working day again, which is why there is a large time gap.

Version number changes are irrelevant for anything shipped inside m-c. Version numbers matter only if we rollout the addon via the system addon update channels, where the version number must be higher than the version we ship in m-c. As be build the .xpi for rollouts from our GitHub repo, not m-c, I only bumped the version number there and didn't bother with pushing the same change to m-c - the commit will be merged in this cycle anyway.

According to the Github commit history, you've imported various patches from Phabricator

Not quite. I imported patches that were already landed in mozilla-central. I did not import any patches that have not been landed, and we'd never do that. Ideally, this would never be required, because people would never change our sources in m-c directly, but only via the GitHub repo. This is unrealistic, of course, because there are many valid reasons why people do work in m-c instead of GitHub, and it's our job to keep track of that and merge the changes back into our "source of truth" before overwriting them. Doing that is part of the process I've linked earlier, so I'm not concerned about such changes.

This is especially relevant because my patch here uses a method that someone is/was going to remove in

I don't think Tom was aware that you used the method, and there is no reason eh should be. That's why reviews exist, and I would have catched that in said review. I didn't get a chance yesterday, because it was already late, but eh.. :) In the worst case, the commit would have blown CI when merged back into the GitHub repo, at which point we'd be able to correct that. Nothing would have been lost.

I hope I could answer your questions. If not, please do ping me again, I'm happy to help out.

Flags: needinfo?(dschubert)

One additional note: You did the right thing by opening a PR. That's generally the way to go if someone wants to add a new intervention. We generally don't expect non-WebCompat-people to build these interventions regularly, but we appreciate any help, and we will make sure that we don't break stuff, as long as the PR is merged (which yours was). So your intervention would have been fine either way. :)

Thanks for that detailed reply. I learned a few things about webcompat's release process from it.

Duplicate of this bug: 1608605

This issue is still reproducible in Nightly 68.5a1 (2020-01-20). Or has the patch not yet been released? My apologies if I am 'jumping the gun'.

As I said, the code will be landed in Nightly during this release cycle, shortly before the end. This is not done yet. :) The soft freeze for this cycle is on 2020-02-06, so I expect the landing to happen the week before. Since this issue happens in Firefox for Android, uplifting the patch will take another couple of days after it has landed in Nightly for Desktop, but I'm pretty sure this patch will be updated as soon as progress started. :)

Firefox Beta 68.5b6 shows that webcompat was at version 6.3.0 (in about:support).
After updating Firefox Beta to the latest version (68.6b1), webcompat is at version 7.0.0.
Google Maps works as expected.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
OS: Unspecified → Android
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.