Closed Bug 1126427 Opened 8 years ago Closed 8 years ago
[FTE] Users can not scroll vertically on the FTU / FTE pages
Description: Not able to scroll during the FTU. This is present during Language selection and Select a Network. This is not present if you follow links to a webpage (such as through Privacy Notice link). This occurs if you: Full Flash, OTA, Settings > Launch FTU, Settings > Reset device Repro Steps: 1) Update a Flame to 20150127010228 2) Attempt to scroll during FTU (Language page) Actual: Device will not scroll Expected: When more content is present, user will be able to scroll down to see it. Environmental Variables: Device: Flame 3.0 Build ID: 20150127010228 Gaia: b02ec9713e6de8d96c6954d2c0dfd0442b0656ac Gecko: 38e4719e71af Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Repro frequency: 5/5 Link to failed test case: https://moztrap.mozilla.org/manage/case/6119/ See attached: logcat ------------------------------------------------------------------------------------------- This issue is NOT present in 2.2 Device: Flame 2.2 (KK - Nightly - Full-Flashed) Build ID: 20150127002504 Gaia: 80d5b797fd0497a7e3337b7798a21b2e1219681a Gecko: 01bf1516a65b Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Mozilla-inbound Regression Window: Last Working Environmental Variables: Device: Flame 3.0 BuildID: 20150126062631 Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: 0bec74187553 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 First Broken Environmental Variables: Device: Flame 3.0 BuildID: 20150126065334 Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: babd56077826 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Last Working Gaia First Broken Gecko: Issue DOES reproduce Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: babd56077826 First Broken Gaia Last Working Gecko: Issue does NOT reproduce Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: 0bec74187553 http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0bec74187553&tochange=babd56077826 possibly caused by bug 1116588
Kartikaya, can you take a look at this please? This might have been the result of the work done on bug 1116588
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(bugmail.mozilla)
[Blocking Requested - why for this release]: Nominating this 3.0? since this is a regression and a bad first time experience for a user.
blocking-b2g: --- → 3.0?
I can repro, will investigate this tomorrow.
Assignee: nobody → bugmail.mozilla
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #4) > I can repro, will investigate this tomorrow. Thanks :kats, In the interim, can we do a plain backout for now ? Not too nice to have the same somketests fail two days in a row ?
Note: I see the following lines in logcat whenever I try to scroll in the FTU: E/HWComposer( 210): Non-uniform vsync interval: 14640635834 E/HWComposer( 210): Non-uniform vsync interval: 3376691
This doesn't sound like fallout from silk. You can try setting these two prefs to false. gfx.vsync.hw-vsync.enabled gfx.vsync.compositor Also from https://bugzilla.mozilla.org/show_bug.cgi?id=1126579#c0, i would expect that it would just be janky instead of an inability to scroll.
It's definitely a regression from bug 1116588. There's an opacity:0 iframe sitting on top of the FTU (some facebook thing) which is causing event-regions to get generated that consume all the input. The iframe also has pointer-events:none set so this shouldn't be happening, but there are multiple frames inside the iframe that also take up the full area. This looks a little non-trivial to fix so I agree that backing out bug 1116588 is probably the best thing to do at this point. Will do that in a sec.
This is the dump for the FTU, the opacity item at 0xb1144738 corresponds to the opacity:0 iframe. The LayerEventRegions items inside it (specifically 0xb1143b30, 0xb1143c48, and 0xb1143cd0) are causing the bad hit region to get generated. I think this doesn't happen during gecko hit-testing because the code at http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSubDocumentFrame.cpp?rev=07029b5f00e9#351 which generates those items is skipped if IsForEventDelivery(), but doesn't get skipped when we are building event regions. There might be additional bugs here too with not properly checking the nearest ancestor's pointer-events property (i.e. elements that are children of a pointer-events:none element might still be getting hit regions). I need to check that.
Landed the backout for bug 1116588 on m-i: https://hg.mozilla.org/integration/mozilla-inbound/rev/74f29dfebd9c
8 years ago
Depends on: 1126876
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S5 (6feb)
This issue is verified fixed on Flame Master. Result: FTU pages scroll properly. Device: Flame Master (319mb, full flash) Build ID: 20150129010239 Gaia: 9d2378a9ef092ab1fc15c3a9f7fc4171aab59d57 Gecko: 6bfc0e1c4b29 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Moving the bug to the component where the regression came from.
blocking-b2g: 2.5? → 2.5+
Component: Gaia::First Time Experience → Layout
Product: Firefox OS → Core
You need to log in before you can comment on or make changes to this bug.