916379 - [B2G][Browser][Webpages]Some webpages do not correctly resize to the devices resolution until refreshed

Status: RESOLVED FIXED

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

Description

[gbennett]

Description:
Some websites load as if user was on a larger resolution device (like PC/laptop) and only shows a very small top left corner portion of the site. Upon refreshing the site reloads correctly adjusting to the resolution of the device browser window, thus allowing a full view of the site and letting the user freely choose where to zoom in or navigate.

Repro Steps:
1) Updated Buri 1.2 mozRIL to Build ID: 20130913040201
2) Open browser
3) Go to hats.com

Actual:
The site loads zoomed in.

Expected:
The site loads correctly formatted to the browser's window resolution.

Environmental Variables
Device: Buri 1.2 mozRIL
Build ID: 20130913040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/b9029b1de410
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Platform Version: 26.0a1

Notes: I tried to repro this issue on my droid phone in FF and could not repro as the page loads normally unlike the Buri.
Repro frequency: 90%
See attached: http://www.youtube.com/watch?v=EmdyLhong-Q
Optional workarounds that may have been identified: REFRESHING THE PAGE 1-2 TIMES USUALLY FIXES THIS ISSUE AND CORRECTLY LOADS THE SITE WITHIN THE RESOLUTION OF THE PHONE/DEVICE. It can also reload the page incorrectly reproducing the bug as well.

Comment 1

[Jason Smith [:jsmith]]

Could be the same problem cited in bug 911345.

Comment 2

[Shilpa Suresh]

This issue does NOT reproduce on Buri v1.2 09/12 build

Environmental Variables
Build ID: 20130912040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/a98569f21abe
Gaia: 9ffd2899eb91388f7fc1ce6f7a895a6f5f922c05
Platform Version: 26.0a1


This issue reproduces on Buri v1.2 09/13 build.
Some webpages do not correctly resize to the devices resolution until refreshed

Environmental Variables
Build ID: 20130913040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/b9029b1de410
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Platform Version: 26.0a1

Comment 3

[Jason Smith [:jsmith]]

Note - this is likely a gecko bug, although I don't know who would work on this. Brad probably knows.

Comment 4

[ffos-browser]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/57246078

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I think these might all be related/duplicates : bug 919039, bug 911345 ,bug 915592

Personally I think this bug is a direct duplicate of bug 915592

Comment 6

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

I've started looking into this. It appears to be a race condition with messages going back and forth between the child and parent process. Sometimes the last frame metrics (the one that "wins") clobbers the earlier correct one. I'll try to come up with a good fix for this - we had similar problems in the early days of Native Fennec but it's a little trickier here because communication in both directions is asynchronous.

Comment 7

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

Attachment: Patch

This fixes the problem for me. I originally added this code back in bug 866232 (see bug 866232 comment 35) and I no longer see that problem when I remove the code. I hope that it has been fixed in some other place. If it does resurface at least I have a better understanding of how this all works now and can hopefully come up with a more correct fix.

Comment 8

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

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

Comment 9

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

Follow-up to fix the gtest which I forgot to run locally:

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

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f6e27e069346
https://hg.mozilla.org/mozilla-central/rev/d986fa70740b

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/844587e80414