bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

[B2G][Flame][FTE] Outlook contact import list sometimes displays an abnormal touch register

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::First Time Experience
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: rpribble, Unassigned)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 affected)

Details

(Whiteboard: [2.0-flame-test-run-2], URL)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8442253 [details]
ContactsFile.csv

Description:
When importing contacts from Outlook during the FTE, selecting the contact lowest on the selection list can sometimes result in the user's touch registering and highlighting area below the contact name and selecting contacts other than those that are being touched, and breaking the 'select all' and 'deselect all' buttons functionalities. Contacts with special characters are displayed at the very bottom of the list underneath the '#' category. 
Contacts with special characters (ñ) display this issue more frequently. 
Contacts containing alt characters (♥,‡,♣) show a 100% repro rate. 
I have not been able to repro this issue while in any other import source (Gmail, Facebook, etc.) other than Outlook.

Prerequisites:
Import attached .csv file to your Outlook account. If the special characters do not import correctly, manually create an Outlook contact with the name '♥♦♣☻?!§¥ñ∞' and no other info.

Repro Steps:
1) Update a Flame to BuildID: 20140616000203
2) Enable data in FTE
3) On 'import contact' page of FTE, select Outlook
4) Log in > scroll down to bottom of list > tap the contact with alt symbols

Actual:
Tough register begins to act abnormally and can break other elements in the contact list (selection check marks, selection buttons).

Expected:
No abnormal touch register and alt characters are handled successfully.

v2.0 Environmental Variables:
Device: Flame v2.0 MOZ ril
BuildID: 20140616000203
Gaia: a6988c15b361938bea5976c846c147ecdc1121c0
Gecko: 52a276202888
Version: 32.0a2
Firmware Version: v121-2


Notes:


Repro frequency: 100% with alt character, 40% with normal text
Link to failed test case: https://moztrap.mozilla.org/manage/case/7251/
See attached: Video
This issue DOES reproduce on Flame 2.1, Buri2.1, Open C 2.1, Flame 2.0, Buri 2.0, and Open C 2.0

Flame 2.1

Environmental Variables:
Device: Flame Master
Build ID: 20140618040513
Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7
Gecko: 37f08ddaea48
Version: 33.0a1 (Master) 
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Open_C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140618040513
Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7
Gecko: 37f08ddaea48
Version: 33.0a1 (Master) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140618073003
Gaia: 336c30b6147cdd9122ad0b2bbffb81eb869a9ec2
Gecko: 1cea544c74c5
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140618063014
Gaia: 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko: 883d156210cf
Version: 32.0a2 (2.0) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Open_C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140618000202
Gaia: 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko: 55679dc2e72b
Version: 32.0a2 (2.0) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Touch register begins to act abnormally and can break other elements in the contact list (selection check marks, selection buttons) when selecting a contact with special characters


This issue does NOT reproduce on Flame 1.4, Buri 1.4 or Open C 1.4

Buri 1.4

Environmental Variables:
Device: Buri 1.4
Build ID: 20140618063004
Gaia: fc74015d26bcbc3e31a45d34cb65777112a35982
Gecko: fab72d8aa2e0
Version: 30.0 (1.4) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Flame 1.4

Environmental Variables:
Device: Flame 1.4
Build ID: 20140618000203
Gaia: 3bdd037ec1a11abebe16a5d7f6ff0d863e80bc07
Gecko: 523491fa3339
Version: 30.0 (1.4) 
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Open_C 1.4

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140618000203
Gaia: 3bdd037ec1a11abebe16a5d7f6ff0d863e80bc07
Gecko: 523491fa3339
Version: 30.0 (1.4) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

When selecting any contact, or any selection options everything behaves as expected.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Please attach a logcat for this issue. Also, no user agent was included for the Flame 2.0 device.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(dharris)
Created attachment 8442383 [details]
Logcat Open C 2.0

Logcat of the issue using Open C instead of flame per bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1010993

User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(dharris)
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Kevin - I'd like to see an analysis here on whether you think this is a non-minor regression or not to see if this issue should block.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][lead-review-]
Flags: needinfo?(ktucker)
(In reply to Jason Smith [:jsmith] from comment #4)
> Kevin - I'd like to see an analysis here on whether you think this is a
> non-minor regression or not to see if this issue should block.

Oh and one other thing - this is missing a regressionwindow-wanted keyword.
I think this should be nominated as a blocker because it is a regression and it is my understanding that European countries use special characters a lot. This also occurs in contacts after importing contacts through the FTE. 50% of the time this issue will break all touch events when trying to select a contact.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?][lead-review-] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
Keywords: qawanted, regressionwindow-wanted

Updated

4 years ago
Keywords: qawanted
Does it reproduce if we take the a) symbols contact out and b)does it reproduce in the contacts app ?

Updated

4 years ago
Keywords: qawanted

Updated

4 years ago
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [lead-review+]

Updated

4 years ago
QA Whiteboard: [lead-review+]

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+
Keywords: qawanted → regressionwindow-wanted
This issue no longer reproduces on the latest Flame 2.0 and Flame 2.1 builds.

Device: Flame 2.0
BuildID: 20140624093150
Gaia: 7260d58fb2b4665ebe614f94d822b8407bd95f58
Gecko: 23457787dfa1
Version: 32.0a2 (2.0) 
Firmware Version: v122

Device: Flame Master
BuildID: 20140624090716
Gaia: 2944695a89c3281d49dbe5ff9c0cd26c8318e2ba
Gecko: 215b93e07e1d
Version: 33.0a1 (Master) 
Firmware Version: v122

The correct contact is always selected.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Rachel - could I get you to check this in the latest Master and verify that it no longer repros then let me know so I can close it as works-for-me.
Flags: needinfo?(jmitchell) → needinfo?(rpribble)
Spoke with Rachel offline, clearing her need-info.  Please disregard comment 8 - additional testing is under-way.
Flags: needinfo?(rpribble)
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
Keywords: qawanted → regressionwindow-wanted
QA Contact: jharvey
Note for the window - it's probably worth testing to see if this reproduces with edge gestures disabled. If it doesn't, then we know the cause of this bug.

Comment 12

4 years ago
This issue still reproduces with Edge gestures disabled.

Comment 13

4 years ago
Mozilla Inbound

Last Working
Environmental Variables:
Device: Flame 
Build ID: 20140529073016
Gaia: 4142df90c71abdc1e3a87cd37dff1a22d5e38b34
Gecko: 1c823c4af278
Version: 32.0a1 
Firmware Version: v122

First Broken
Environmental Variables:
Device: Flame 
Build ID: 20140529103002
Gaia: b669dd2cc321f37cebc7081a79b968cac36b4200
Gecko: 29ca8bc78484
Version: 32.0a1 (Master)
Firmware Version: v122

Last Working Gaia First Broken Gecko: Issue DOES reproduce
Gaia: 4142df90c71abdc1e3a87cd37dff1a22d5e38b34
Gecko: 29ca8bc78484

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: b669dd2cc321f37cebc7081a79b968cac36b4200
Gecko: 1c823c4af278

Gecko Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1c823c4af278&tochange=29ca8bc78484
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Josh - This is missing a regression window analysis.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review-]
Flags: needinfo?(jmitchell)
oh boy - pushlog is fairly large despite the regression window only spanning 3 hours. 

I did not find anything related to FTE, Special Characters or Touch Register; 
I found one issue related to Contacts so that is my 'best' suspicion  - bug 1016410

Julien - I believe the patch on that bug is yours, can I trouble you to take a look?
Flags: needinfo?(jmitchell) → needinfo?(felash)
(In reply to Joshua Mitchell (Joshua_M) from comment #15)
> oh boy - pushlog is fairly large despite the regression window only spanning
> 3 hours. 
> 
> I did not find anything related to FTE, Special Characters or Touch
> Register; 
> I found one issue related to Contacts so that is my 'best' suspicion  - bug
> 1016410
> 
> Julien - I believe the patch on that bug is yours, can I trouble you to take
> a look?

I don't think that's the cause - that's a test-specific change, which wouldn't cause a user facing regression.
Flags: needinfo?(felash)
I do see bug 897996 & bug 994293 in the range though.

kats - Would either of these bugs affect touch inputs being off from their target?
QA Whiteboard: [QAnalyst-Triage+][lead-review-]
Flags: needinfo?(bugmail.mozilla)
Keywords: qawanted

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Keywords: qawanted
And I don't see how you could find bug 1016410 in the _Gecko_ pushlog ;)
(In reply to Jason Smith [:jsmith] from comment #17)
> I do see bug 897996 & bug 994293 in the range though.
> 
> kats - Would either of these bugs affect touch inputs being off from their
> target?

They shouldn't, no. I don't see anything else in the regression window from comment 13 that would be related either. From the video it looks more like a gaia problem than a platform problem to me, because of the way the blue active-highlight on the contact entry is misplaced. It might be a platform problem in layout also.
Flags: needinfo?(bugmail.mozilla)
What are the next steps here? Can we get a finer regression window?
A finer regression window might help. It might be easier to just start debugging the problem. Whoever owns the outlook contact import list screen should use the app manager or other inspection devtools to look into what element is getting that highlight and why it is misplaced. That might point to bugs in the CSS.
Jose, Francisco, can you help here? Who maintains the outlook import?
Flags: needinfo?(jmcf)
Flags: needinfo?(francisco)
The regression window includes bug 1016086 which got backed out again afterwards. Can we double-check that it doesn't happen with the patch backed out?

Comment 24

4 years ago
we haven't landed anything signifcant there. this seems to be a gecko issue.
Flags: needinfo?(jmcf)
Nobody has landed anything significant in there. We can either do the regression window down to a single check-in, or as suggested in comment 21, forget about the regression window and just debug at the app level.
Do we have a test-account for outlook we can us here?
Chris, is this something you can help with? I am not sure if the regression window makes a lot of sense here. We should just try to debug the underlying problem.
Flags: needinfo?(chrislord.net)
(In reply to Gregor Wagner [:gwagner] from comment #26)
> Do we have a test-account for outlook we can us here?

See account 19 & 20 under https://intranet.mozilla.org/QA:B2G_Hotmail_ActiveSyncTestAccounts.

Can we revalidate the regression window here to be sure this is correct?
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Keywords: regressionwindow-wanted
Gregor will take a look today if it's a gaia problem.
Flags: needinfo?(francisco)
Hi again,

as Jose commented, we dindn't land recently nothing in the outlook importer.

Was trying with latest master and couldn't reproduce anyway, with my spanish account, and also adding a contact with name (♥,‡,♣)

Leaving a video:
https://drive.google.com/file/d/0B3RfQh7fuZjAdU5SSTVCV2E0SmM/edit?usp=sharing

Comment 31

4 years ago
I am also unable to reproduce this issue on the latest Flame master build.

Environmental Variables:
Device: Flame Master
Build ID: 20140709070635
Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec
Gecko: 2d88803a0b9c
Version: 33.0a1 (Master)
Firmware Version: v122
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
I'm confused as to the status of this bug - is comment #13 accurate? If so, could we not just bisect further and find out exactly what's causing the problem?

At a glance, I don't have anything more to offer than what kats has said, though looking at the video, it's possible it could be related to progressive rendering. It looks like the main content area is lagging behind by a paint, perhaps it's stuck with some incorrect metrics for some reason... I'm not sure what chain of events could lead to results like this, but it seems feasible to me.

Can the issue be reproduced with layers.progressive-paint and layers.low-precision-buffer both set to false?

Given that a lot of progressive paint issues have been fixed in the latest master and it's apparently fixed now, it does seem to point to progressive painting.
Flags: needinfo?(chrislord.net)
Multiple parties have been unable to repro this in the latest Master, Chris states a lot of progressive paint issues have been fixed - sounds like a solid Works-For-Me
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(jmitchell)
Resolution: --- → WORKSFORME
blocking-b2g: 2.0+ → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Keywords: regressionwindow-wanted
Did you have someone make sure that this doesn't reproduce on 2.0?
Flags: needinfo?(jmitchell)

Comment 35

4 years ago
This issue does not reproduce on the latest 2.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140709105132
Gaia: 3316542e36084a8d1f6a5446abe9bf199765f3d7
Gecko: 94047c419c3f
Version: 32.0a2 (2.0)
Firmware Version: v122
Flags: needinfo?(jmitchell)
Resolution: WORKSFORME → FIXED

Updated

4 years ago
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.