1247098 - Screen will be blurry during transition when returning to top menu in settings

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: logcat

Summary (title) Field:
Returning to top menu in settings will cause part of screen to be blurry during transition

Description:
if the user is in settings and enters a sub menu (wifi settings, Device information, Display, etc) then reurns to the top level settings menu part of the screen will be blurry or will be blank during the transition.

Repro Steps:
1) Update a Aries to 20160209110317
2) Open settings
3) Enter wi-fi
4) Press arrow in top left of screen to return to top menu
5) Observe left side of screen

Actual:
Part of the screen is blurry when returning to the top menu of settings

Expected:
It is expected that the screen is not blurry during transition.

Environmental Variables:
Device: Aries 2.6 [Full Flash]
Build ID: 20160209110317
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 2dfb45d74f42d2a0010696f5fd47c7a7da94cedb
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 46.0a1 (2.6)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Repro frequency: 10/10
See attached: video clip, logcat

Comment 1

[Adam Alldredge [:AdamA][Inactive]]

This issue DOES occur on Flame 2.6.

Environmental Variables:
Device: FlameKK 2.6 [Full Flash][512mb]
BuildID: 20160209030410
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 2dfb45d74f42d2a0010696f5fd47c7a7da94cedb
Gonk: 8a066f7fa7410e32b58def35f322aa33f03db283
Version: 46.0a1 (2.6) 
Firmware Version: v18D v5
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Result:
Part of the screen is blurry when returning to the top menu of settings
----------------------------------------------
This issue DOES NOT occur on Flame 2.5.

Environmental Variables:
Device: Flame 2.5
BuildID: 20160203175457
Gaia: 8c68247e3045cde7445141e94e94104d617de03b
Gecko: 80f03882ea5ee138dcccc7e7e7c2263ac862a0fa
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Result:
Screen is not blurry during transition.

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

Please check the regression window for bug 1247111 against this issue to see if this is a dupe.

Comment 3

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1241917 or Bug 1245550 seem to have caused this issue.

Mozilla-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.6
BuildID: 20160205022909
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 2ada62724f2af8b0d6c104e3bd249ab28d021d2f
Version: 46.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

First Broken 
Environmental Variables:
Device: Flame 2.6
BuildID: 20160205023409
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 915eba5053164dd0bed86f6527b823fb7cb4b564
Version: 46.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 915eba5053164dd0bed86f6527b823fb7cb4b564

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 2ada62724f2af8b0d6c104e3bd249ab28d021d2f

Gaia Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2ada62724f2af8b0d6c104e3bd249ab28d021d2f&tochange=915eba5053164dd0bed86f6527b823fb7cb4b564

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Lee and Jamie I'm not sure which of your changes may have caused this issue but can you please take a look?

Comment 5

[Lee Salzman [:lsalzman]]

I don't think my changes would have affected that. The mfbt Function change should have no semantic effects on existing code, and the texture-from-pixmap wouldn't be used here, nor was it ever used anywhere by default.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

This might be the related to the problem I was seeing in Fennec.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Carrying dependency from dupe.

Comment 10

[Jamie Nicol [:jnicol]]

tn, I'm a bit stuck on this, wondering if you have any ideas?

We're managing to get the root comp bounds correctly in ScrollFrameHelper::DecideScrollableLayer(), but the nsLayoutUtils::GetTransformToAncestor() call is only translating them, not scaling them. None of the Frames between the mOuter frame and the root frame have IsTransformed() = true. (So nsIFrame::GetTransformMatrix() only translates and doesn't scale). I can however see the correct transform in the layer tree. One of the frames belongs to a Resolution display item, so I would have thought it would be IsTransformed(). I'm not sure where to look next.

(Note I'm using the STR from bug 1247499 since I don't have a b2g setup)

Comment 11

[Timothy Nikkel (:tnikkel)]

Dang, I messed up. I specifically thought through this issue for the original bug, but I guess I got it wrong.

I think you need to adjust the return value of CalculateCompositionSizeForFrame for the resolution if the frame is the root scroll frame of the root content document, just like we are warned here:

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.h#2572

Here is an example of doing that:

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#3201

Comment 12

[Jamie Nicol [:jnicol]]

Attachment: MozReview Request: Bug 1247098 - Mark nsIPresShell::GetResolution and nsPresContext::IsRootContentDocument as const; r?tnikkel

Review commit: https://reviewboard.mozilla.org/r/36309/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/36309/

Comment 13

[Jamie Nicol [:jnicol]]

Attachment: MozReview Request: Bug 1247098 - Take document resolution into account when computing root composition bounds for displayport base; r?tnikkel

nsLayoutUtils::CalculateCompositionSizeForFrame() is not affected by the
document resolution when called for the root content document's root
scroll frame. When determining the root composition bounds in order to
calculate a displayport base, if the frame used is the RCD-RSF we must
be sure to scale the bounds ourselves by the document resolution.

Review commit: https://reviewboard.mozilla.org/r/36311/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/36311/

Comment 14

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8723093 [details]
MozReview Request: Bug 1247098 - Mark nsIPresShell::GetResolution and nsPresContext::IsRootContentDocument as const; r?tnikkel

https://reviewboard.mozilla.org/r/36309/#review32909

Comment 15

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8723095 [details]
MozReview Request: Bug 1247098 - Take document resolution into account when computing root composition bounds for displayport base; r?tnikkel

https://reviewboard.mozilla.org/r/36311/#review32911

Comment 16

[Jamie Nicol [:jnicol]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1ecafda197d&selectedJob=17172322

Comment 17

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1194660fd742
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed985bbb417f

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1194660fd742
https://hg.mozilla.org/mozilla-central/rev/ed985bbb417f