1505803 - "Date" input field cannot be set, calendar not triggered

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Keyboards and IME, defect, P1)

Description

[Mira Lobontiu (Android QA)]

Attachment: 2018_11_08_16_37_08.mp4

Devices:
 - Sony Xperia Z5 Premium (Android 6.0.1);
 - Nokia 6 (Android 7.1.1);

Build(s):
 - Nightly 65.0a1 (2018-11-07)

Steps to reproduce:
 1. Go to https://daleharvey.github.io/testapp/
 2. Tap on "Date" or "mm/dd/yyyy" input field.

Expected result:
 The calendar should be triggered.

Actual result:
 the text is selected, but the calendar is not triggered.

Notes:
 Not reproducible on Release 63.0.2, and Beta 64.0b7.

Ran a regression:
Last good revision: 79fe86c6047bd5e5580320f2f041a29e9fa2759b
First bad revision: 97db91af91fde137e9d56189e3edcd9c5a8aee27
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=79fe86c6047bd5e5580320f2f041a29e9fa2759b&tochange=97db91af91fde137e9d56189e3edcd9c5a8aee27

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Xidorn, could you look in to this?

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

It's very unlikely that backout of bug 1473816 can cause this... but I'll have a look later.

Also the backout is also down in beta at https://hg.mozilla.org/releases/mozilla-beta/rev/e406bf1c8cd4

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

So, mozregression indeed points to the backout, but the backout itself doesn't seem to be where the regression comes from. If you run the build of the backout 97db91af91fd (on mozilla-inbound), this issue is not reproducible, but if you run the build of the consequent merge ef27c14b46bf, this issue happens.

So somehow it is the issue of the merge, and the specific commit is blamed just because it happens to be the last commit before that merge.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

So, mozregression indeed points to the backout, but the backout itself doesn't seem to be where the regression comes from. If you run the build of the backout 97db91af91fd (on mozilla-inbound), this issue is not reproducible, but if you run the build of the following merge ef27c14b46bf, this issue happens.

So somehow it is the issue of the merge, and the specific commit is blamed just because it happens to be the last commit before that merge.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Recent regression in 65, would be good to investigate.

Comment 6

[Mira Lobontiu (Android QA)]

Hi,

I have rerun the regression today, twice, with the same result:
 Last good revision: 74c6ef5cd2d77596878e975974598a7aa4dd5613
 First bad revision: 97db91af91fde137e9d56189e3edcd9c5a8aee27

 Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=74c6ef5cd2d77596878e975974598a7aa4dd5613&tochange=97db91af91fde137e9d56189e3edcd9c5a8aee27

Sorry for the confusion,

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

mozregression likely gives the same result, which is a limitation of the tool. It doesn't take merge into consideration.

But looking at the merge itself, it is also unclear to me how this can happen...

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

Maybe someone from the Android team should look into that and see what's really happening there rather than trying to figure out what change makes it going wrong.

Comment 9

[Bogdan Surd, QA [:bsurd, NI]]

@Susheel could you assign someone to look over this?

Comment 10

[:sdaswani]

Liz should this stay as a P2?

Comment 11

[Petru-Mugurel Lingurar [:petru]]

According to the report, the issue was a recent regression, only happening on Nightly builds.

Tried to reproduce on latest Nighly on a Samsung S8 (Android 8.0) and on a Moto E (Android 7.1.1) and could not reproduce.

Mira, is this still an issue or has been resolved in the meantime?

Comment 12

[Mira Lobontiu (Android QA)]

 Hi Petru,

 I`ve tested on Nokia 6 (Android 7.1.1) and Sony Xperia Z5 Premium (Android 6.0.1) on the latest Nightly 65.0a1 (2018-12-03) and it is not reproducible anymore.
Therefore, I will close this issue as WORKSFORME.

 Thank you!