1200093 - trying again to load 127.0.0.1 pushes ui below home button

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

User-Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

STR

* load 127.0.0.1 in rocket bar
* you'll see a network error
* choose "try again"

the buttons will now be partially behind the software home button.

Comment 1

[Mahendra Potharaju [:mahe]]

[Blocking Requested - why for this release]: Broken functionality. Nominating for 2.5

Comment 2

[Gregor Wagner [:gwagner]]

Is this a regression?

Comment 3

[Max Ivanov[:MaxIvanov]]

I was able to reproduce this on Aries 2.5 and Flame 2.5 and wasn't on Flame 2.2.

Device: Aries 2.5
Build ID: 20150903220207
Gaia: d7385b79e68d4ad662cacf810506e9ee53345d23
Gecko: 7f987c38bd3e5ac9a834981e85378bdb02338e9d
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.5
Build ID: 20150903041524
Gaia: a55d3d512a765bd483bd595b0c8f80c5f1d61b65
Gecko: 74fbd245369c474beaa7f2b1959570243e3dafaa
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.2
Build ID: 20150901123002
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: c03e2bc6a3a4
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 4

[Michael Bryant (uber)]

Initial Regression Window:

Last working build:

Device: Flame
Build ID: 20150721010202
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: 3a4bfa5d2d02
Version: 42.0a1

First broken build:

Device: Flame
Build ID: 20150721160205
Gaia: 84c3bf622e211046d905803b34de5d331761f22d
Gecko: 1875a5584e5f
Version: 42.0a1

First broken Gaia with last working Gecko - Issue does NOT reproduce

Gaia: 84c3bf622e211046d905803b34de5d331761f22d
Gecko: 3a4bfa5d2d02

Last working Gaia with first broken Gecko - Issue DOES reproduce

Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: 1875a5584e5f

Gecko Push Log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3a4bfa5d2d02&tochange=1875a5584e5f

Comment 5

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

Let's get a tighter window on this from an inbound.  Start from Michael's central window.

Comment 6

[Martin Shuman [:Marty]]

This issue appears to be caused by:
Bug 1178847 - Refactor code that computes the CSS viewport

Mozilla-inbound Regression Window

Last Working
Environmental Variables:
Device: Flame 2.5
BuildID: 20150721075041
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: 49ae0961591e
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20150721075241
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: fee45cd9a4d9
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Last Working gaia / First Broken gecko - Issue DOES reproduce
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: fee45cd9a4d9

First Broken gaia / Last Working gecko - Issue does NOT reproduce
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: 49ae0961591e

Gecko Pushlog: 
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=49ae0961591e&tochange=fee45cd9a4d9

Comment 7

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

Kartikaya, this issue seems to have been caused by the changes for bug 1178847.  Can you please take a look?

Comment 8

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

I chased this through a bunch of code and it looks like the document's widget is coming back as null at [1] which causes the code to use 1.0 instead of 2.0 as the CSSToLayoutDeviceScale. This ends up sizing the document to twice as tall/wide as it should be in CSS pixels, and the gaia code that handles the mozbrowserscrollareachanged event [2] then makes the app window "scrollable", resulting in the visual bug.

Getting a null widget for a document seems not entirely uncommon since when I added a log line there it got hit for a bunch of different documents. I think not relying on finding the widget to get the CSSToLayoutDeviceScale would be a good idea here.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp?rev=1eb12ed3b236#7901
[2] https://github.com/mozilla-b2g/gaia/blob/f58120447bc37eafae03ba83cf0ddc129207eca1/apps/system/js/app_chrome.js#L709

Comment 9

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

Attachment: Patch

This does the job. Kicked off a try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=ec5320b69ac8

Comment 10

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

Try push is green; the wpt failures are pre-existing.

Comment 11

[Botond Ballo [:botond]]

Comment on attachment 8657648 [details] [diff] [review]
Patch

Review of attachment 8657648 [details] [diff] [review]:
-----------------------------------------------------------------

Just for posterity: in the scenarios that this bug fixes, there still is a widget, and the widget's scale is used as an ingredient in nsPresContext::AppUnitsPerDevPixel(), it's just that nsContentUtils::WidgetForDocument() doesn't find the widget, so the old code wasn't getting the correct scale.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/b2g-inbound/rev/338f610603fb

Comment 13

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/338f610603fb