Closed Bug 1148350 Opened 10 years ago Closed 10 years ago

[Flame][Email]It may enter the next adjacent folder when you want to enter one of the folders in Inbox view.

Categories

(Core :: Panning and Zooming, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla40
blocking-b2g 2.2+
Tracking Status
firefox38 --- wontfix
firefox38.0.5 --- wontfix
firefox39 --- wontfix
firefox40 --- verified
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: wangxin, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(5 files)

[1.Description]: [Flame][v2.2][Email] In Inbox view, try to switch between Inbox/Drafts/Local Drafts/Outbox/Send folder by tapping menu button on top left, device will not enter the folder we selected, instead, it may enters the next folder. Attchment: logcat_431.txt and 431.mp4 Happen time: 4:31 PM [2.Testing Steps]: 1.Launch Email 2.Set up an mail account (ex. Gmail account) 3.Tap Menu button on top left 4.If you are not in Inbox, tap Inbox, then tap Menu button on top left again 5.Tap Inbox/Drafts/Local Drafts/Outbox/Send to switch folder [3.Expected Result]: 5.It should enter the folder we selected. [4.Actual Result]: 5. It may enters the next folder. [5.Reproduction build]: Flame 2.2 build: Affected Build ID 20150326002504 Gaia Revision e59ac067a1d22b7a72cbebc892ec652723f2a557 Gaia Date 2015-03-26 00:02:53 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/04b4b9d1faae Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150326.042521 Firmware Date Thu Mar 26 04:25:30 EDT 2015 Bootloader L1TC000118D0 Device:Flame 3.0: Unaffected Build ID 20150326160206 Gaia Revision 525c341254e08f07f90da57a4d1cd5971a3cc668 Gaia Date 2015-03-26 16:34:16 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/59554288b4eb Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150326.193247 Firmware Date Thu Mar 26 19:32:58 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: occasionally Recurrence,4/5 [7.TCID]: Free Test [8. Note]: If It enters the next folder in step 4. Please repeat step 4.
Attached video Bug video: 431.mp4
Hm, there's probably an APZ fix that needs to be uplifted to v2.2. It might be worth trying a v3.0 build from maybe a week ago and see if it has the problem. If it also doesn't have the problem, then the fix probably won't be uplifted without a request on our end and then we'd want a more thorough bisection.
Flags: needinfo?(twen)
(In reply to Andrew Sutherland [:asuth] from comment #2) > Hm, there's probably an APZ fix that needs to be uplifted to v2.2. It might > be worth trying a v3.0 build from maybe a week ago and see if it has the > problem. If it also doesn't have the problem, then the fix probably won't > be uplifted without a request on our end and then we'd want a more thorough > bisection. Hi Andrew, I am able to reproduce this on v3.0 Build-ID 20150320160205. Repro rate is 100% on the first try every time email app is opened. v3.0 Build Gaia-Rev 8837f94418d69a0b06c1f4843b0779e2bb72165a Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/5e198fd4017f Build-ID 20150320160205 Version 39.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150320.191809 FW-Date Fri Mar 20 19:18:22 EDT 2015 Bootloader L1TC000118D0
Flags: needinfo?(twen)
Okay, so then I guess we need to figure out what APZ fix landed on v3.0 that's not on v2.2 yet. Or we can just wait a little longer and hope that the APZ people already are in the process of uplifting the fix.
See Also: → 1152274
Does this still occur with the latest 2.2 code? If it does, we should get a fix window to see what fixed it on 3.0.
Flags: needinfo?(wangxin)
Hi Botond, This bug still exsits on lates Flame 2.2 STR is the same as comment 0. occasionally Recurrence,4/5 See log 'logcat_958.txt' found time: 9:58 PM Flame 2.2(Fail): Build ID 20150422002505 Gaia Revision 41a85c5f9db291d4f7c0e94c8416b5115b4ee407 Gaia Date 2015-04-21 17:23:41 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a87a05e7d0ef Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150422.040316 Firmware Date Wed Apr 22 04:03:27 EDT 2015 Bootloader L1TC000118D0
Flags: needinfo?(wangxin) → needinfo?(botond)
Thanks! This means the issue was fixed on the 3.0 branch, and the fix hasn't been uplifted to 2.2. It would be great to get a fix window on the 3.0 branch, so we know what the fix was and see if we can uplift it.
Flags: needinfo?(botond)
QA Contact: ychung
I was able to reproduce this issue on the latest Flame Master. I changed the tracking flag to affected for 3.0, and unaffected for 2.1, as the selected folder always appears properly. Environmental Variables: Device: Flame 3.0 Build ID: 20150423065001 Gaia: 4d87112bbf48cdd09c19e553cc9aebd2a2c4ddfd Gecko: 10a237997b8d Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Environmental Variables: Device: Flame 2.2 BuildID: 20150423074202 Gaia: b838d0e7c163e66660dcb6e387d8339944a7a30e Gecko: 5fe76b26e55f Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Environmental Variables: Device: Flame 2.1 BuildID: 20150422095813 Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c Gecko: 6a68a038146a Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------ I will work on getting a regression window and see what happens.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I was unable to get a regression window as the repro rate is as low as 1/20 on central builds. The following build is the earliest build I could reproduce: Environmental Variables: Device: Flame 3.0 BuildID: 20150317034728 Gaia: 738987bd80b0ddb4ccf853855388c2627e19dcc1 Gecko: 008b3f65a7e0 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Nominate for v2.2 blocking, because function UI broken; it always misses the intended folder and opens the next folder in view. (Tap "Sent Mail" folder will go into Mail settings) Will only gets it right starting from second tap. Repro rate is still 100% on the first try every time email app is opened. Gaia-Rev b838d0e7c163e66660dcb6e387d8339944a7a30e Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5fe76b26e55f Build-ID 20150423162502 Version 37.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150423.195827 FW-Date Thu Apr 23 19:58:39 EDT 2015 Bootloader L1TC000118D0
blocking-b2g: --- → 2.2?
Noticed a workaround: if user drag the folder menu down first before tapping on the folder, it would open the correct folder. Interestingly, repro rate is lower on master, but almost 100% if you tap on "Sent Mail" which will open "Mail Settings" incorrectly. Gaia-Rev 0c5e2ee1173f3c53379ef3cd10de714836258fe8 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/22a157f7feb7 Build-ID 20150423160207 Version 40.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150423.193607 FW-Date Thu Apr 23 19:36:18 EDT 2015 Bootloader L1TC000118D0 Also note, this is not found on nexus-5-L master. Gaia-Rev 0c5e2ee1173f3c53379ef3cd10de714836258fe8 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/22a157f7feb7 Build-ID 20150423160207 Version 40.0a1 Device-Name hammerhead FW-Release 5.1 FW-Incremental eng.cltbld.20150423.192918 FW-Date Thu Apr 23 19:29:36 EDT 2015 Bootloader HHZ12d
QA Contact: ychung
I'm able to reproduce this issue more consistently if I press and hold the folder for a moment. Going to try and pick up the window where Yeojin left off.
QA Contact: jmercado
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Bug 1109873 seems to have caused this issue. Mozilla-inbound Regression Window Last Working Environmental Variables: Device: Flame 2.2 BuildID: 20150108061600 Gaia: d4dac29613076bdba3cb8adc217deadb08a2ac20 Gecko: 3b29b9cdedfc Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 First Broken Environmental Variables: Device: Flame 2.2 BuildID: 20150108064122 Gaia: 82b534791a72ad59c78363df80459e18d35b48f8 Gecko: 5d506eb6fd4c Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Last Working gaia / First Broken gecko - Issue DOES occur Gaia: d4dac29613076bdba3cb8adc217deadb08a2ac20 Gecko: 5d506eb6fd4c First Broken gaia / Last Working gecko - Issue does NOT occur Gaia: 82b534791a72ad59c78363df80459e18d35b48f8 Gecko: 3b29b9cdedfc Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3b29b9cdedfc&tochange=5d506eb6fd4c
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Kartikaya or Botond, can you take a look at this issue please? This might have been caused by the work done for bug 1109873.
Blocks: 1109873
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
I can reproduce, investigating.
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(botond)
Ok, so what appears to be happening here is that the layer tree changes while we're in the middle of a tap (because the touch-down of the tap sets a displayport and changes layerization). As a result, the APZ that is receiving the input block moves to a different place in the layer tree such that the screen-to-apzc transform is different. When APZCTM applies the untransform, it uses "live" values (at [1]) so there's no problem. However, the events that go into the APZC use a cached screen-to-apzc transform (at [2]). For the most part this is ok, but it causes a problem when in ConvertToGecko because there we take the input event that was transformed with the cached value, and untransform it into gecko space using a live value [3]. The mismatch between the screen-to-apzc transform (using the original layer tree) and the apzc-to-gecko transform (using the modified layer tree) is what causes the problem. I wrote up a patch which fixes this by changing ConvertToGecko to take the screen-coordinate point and use live screen-to-apzc and apzc-to-gecko transforms. This way it mirrors what we're doing in APZCTreeManager at [1] and also fixes this bug. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/APZCTreeManager.cpp?rev=fbbca69d29e8#766 [2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/InputBlockState.cpp?rev=fbbca69d29e8#148 [3] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?rev=fbbca69d29e8#1401
Attached patch PatchSplinter Review
Attachment #8598806 - Flags: review?(botond)
Component: Gaia::E-Mail → Panning and Zooming
Product: Firefox OS → Core
Attached patch TestSplinter Review
Attachment #8598834 - Flags: review?(botond)
Attachment #8598806 - Flags: review?(botond) → review+
Attachment #8598834 - Flags: review?(botond) → review+
triage: regression which breaks basic function
blocking-b2g: 2.2? → 2.2+
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment on attachment 8598806 [details] [diff] [review] Patch NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 1109873 exposed it User impact if declined: sometimes clicks get delivered to the wrong coordinates Testing completed: local, added a unit test also Risk to taking this patch (and alternatives if risky): fairly low risk, the code changes are pretty straightforward String or UUID changes made by this patch: none
Attachment #8598806 - Flags: approval-mozilla-b2g37?
Attachment #8598834 - Flags: approval-mozilla-b2g37?
This bug has been verified on latest Flame 3.0, Same STR with comment0. Flame3.0 build(Pass): Build ID 20150503160200 Gaia Revision e18cce173840d6ff07fb6f1f0e0ffb58b99aab3e Gaia Date 2015-05-02 04:27:01 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/dc5f85980a82 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150503.193941 Firmware Date Sun May 3 19:39:52 EDT 2015 Bootloader L1TC000118D0
Attachment #8598806 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8598834 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Backed out for build bustage in the newly-added test. Note that I had to rebase the first patch as well. https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2df83538ae20 https://treeherder.mozilla.org/logviewer.html#?job_id=116425&repo=mozilla-b2g37_v2_2
Flags: needinfo?(bugmail.mozilla)
Looks like the test has a dependency on bug 1092128, which has not been uplifted to b2g37.
Add "verifyme" keywords for Flame v2.2 uplift and verification.
Keywords: verifyme
I rebased them locally on 2.2, verified stuff builds and the gtests pass, and landed: remote: https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/58bc95a30f7e remote: https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/3af6a0a79227
Flags: needinfo?(bugmail.mozilla)
This bug has been verified successfully on latest Flame 2.2, Same STR with comment0. Repro Rate: 0/10 Flame2.2 build(Pass): Build ID 20150506002501 Gaia Revision 772a9491909abd02dc67278dd453746e2dd358a8 Gaia Date 2015-05-05 02:02:24 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/3af6a0a79227 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150506.040209 Firmware Date Wed May 6 04:02:20 EDT 2015 Bootloader L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Comment 23 shows the v3.0 (master) test result. Set firefox40=verified and change bug status to "VERIFIED FIXED"
Status: RESOLVED → VERIFIED
No longer blocks: 1152274
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: