982821 - [B2G][Browser] Rotating the phone to landscape mode in browser causes the screen to be blocked by a white box.

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Harvey]

Description: When the user rotates the phone whilst the browser is on the "Network connection unavailable" screen a white box will block some of the screen.

Repro Steps:
1) Update a Buri to BuildID: 20140312040203
2) Do not be connected to any networks (i.e Edge, WiFi)
3) Select Browser.
4) Go to a website url without having their cookies. 
5) On the "Network connection unavailable" screen, rotate the phone to landscape.

Actual:
A white box appears and blocks some of the screen.

Expected:
None of the visuals are blocked.

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140312040203
Gaia: 3005269d4dcabcc7d27eaf72bda44a969873af8c
Gecko: 23005b395ae8
Version: 30.0a1
Firmware Version: v1.2-device.cfg


Repro frequency: 100%
See video: https://www.youtube.com/watch?v=4HTxgrIfq4M

Comment 1

[Harvey]

This issue also happens on normal websites when the page is scrolled to the top and the phone is rotated to the left.

Comment 2

[Jason Smith [:jsmith]]

QA Wanted to check behavior on 1.3.

Comment 3

[Harvey]

This issue does not reproduce on 1.3

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140313004002
Gaia: 6194def5ceed3f4b9bc9de0ea2c11661cd439a27
Gecko: 9368fd13bfa6
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 4

[Chris Kreinbring [:CKreinbring]]

Regression windows:

TINDERBOX
No repro
Build ID: 20140311040203
Gecko: https://hg.mozilla.org/mozilla-central/rev/41d962d23e81
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg

Repro
Build ID: 20140311122009
Gecko: https://hg.mozilla.org/mozilla-central/rev/9cdaf3f7c601
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg

Working Gaia / Broken Gecko = Fail
Broken Gaia / Working Gecko = OK
Gecko push log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=41d962d23e81&tochange=9cdaf3f7c601


MOZILLA INBOUND
No repro
Build ID: 20140310192240
Gecko: https://hg.mozilla.org/integration/mozilla-inbound/rev/cafc246cc62c
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg

Repro
Build ID: 20140310204542
Gecko: https://hg.mozilla.org/integration/mozilla-inbound/rev/c234a1aeaeab
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Platform Version: 30.0a1
Firmware Version: V1.2-device.cfg

Inbound push log: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cafc246cc62c&tochange=c234a1aeaeab

Comment 5

[Jason Smith [:jsmith]]

bug 979489 appears to be the cause.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Nical, isn't this the bug you were mentioning in a daily?

Comment 8

[Nicolas Silva [:nical]]

The bug I was mentioning in the daily was that the clip rect that is passed in RenderLayer is in the coordinate space of the destination frame buffer, so it doesn't take landscape mode into account on b2g, while layer's coordinates are in roughly the same space, except that, more or less, x and y axis are flipped in landscape mode. So as long as we only use the clip rect to pass it to the shader it's good, but if we compare the layer or tile's coordinates with the clip rect we get into trouble (that's what we were doing with TiledContentHost here: http://dxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TiledContentHost.cpp#325 except that this was fixed by the addition of ClipRectInLayersCoordinates).

My understanding is that simple tiles use TiledContentHost just like the other TiledContentHost, so if this is the same clipping bug, it should have been fixed along with the other TiledContentHost.

Comment 9

[Sotaro Ikeda [:sotaro]]

The problem seems to be already fixed on master hamachi. I can not reproduce the problem in the STR in Comment 0.

Comment 10

[Peter Bylenga [:PBylenga]]

Attachment: Browser_White_Box_v14.png

This issue reproduces still on v1.4 Aurora but is not 100% more like 30-40% repro rate.

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140318000203
Gaia: c03a6af9028c4b74a84b5a98085bbb0c07261175
Gecko: 3776f72f1967
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Issue also reproduces on today's master v1.5 build at the same repro rate as v1.4

v1.5 Environmental Variables:
Device: Buri v1.5 MOZ
BuildID: 20140318040206
Gaia: c03a6af9028c4b74a84b5a98085bbb0c07261175
Gecko: 5d61fabc49a8
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's give this a day to make sure all the changes have propagated through.

Comment 12

[Nicolas Silva [:nical]]

I just did a full flash of my hamachi with a master image from pvt and I can't reproduce this bug.

Comment 13

[Jason Smith [:jsmith]]

Flagging qawanted again to test again on the latest bits. If it still reproduces, then we'll need an updated video showing off the bug.

Comment 14

[Peter Bylenga [:PBylenga]]

I am able to reproduce this issue on today's buri v1.4 build using the duplicate's (bug 982716) STRs although at the much lower reproducibility rate of <5%.  In the video I loaded comments for the m.youtube video and then rotated the phone which made it easier to reproduce.

https://www.youtube.com/watch?edit=vd&v=mOCUiRnDgmc

v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20140320000349
Gaia: 53edbf08b0a750c31e8c6b2c20f2b1315b1412d1
Gecko: 9b482d6994fd
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 15

[Jason Smith [:jsmith]]

I think that's a different bug than this - the STR used to generate the white part is very different than this bug's original STR. Can you file a new bug about this issue with the reduced STR used to reproduce it?

Comment 16

[Peter Bylenga [:PBylenga]]

Filed bug 986248 to address the additional steps of loading comments while a video is streaming to reproduce the issue.