Closed Bug 799530 Opened 9 years ago Closed 6 years ago

Pages load slightly zoomed in

Categories

(Core :: Layout, defect)

All
Android
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
fennec - ---

People

(Reporter: kats, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

At some point when nightly was 18, I noticed that pages would load slightly zoomed in. Tested on a Galaxy Nexus on recent m-c and it's still happening. Filing this bug to get a regression range and fix.

STR: load bugzilla.mozilla.org
Expected: the entire width of the page should be visible
Actual: the right edge of the page is off-screen; the page can be pinch-zoomed to make it fit.
Tested this on Galaxy Nexus (Android 4.1.1) using Nightly 19.0a1 2012-10-09.
The page loads at default zoom level first(the entire width of the page is visible)  but only after reloading the page the content is zoomed-in. Is this the correct way to reproduce this issue?
No, for me it happens on the first load of the page. Although I just tried it a few times and it does seem a little random in that it doesn't happen every single time. You might have to open and close Fennec a few times to see it.

As an aside, it's weird that the Login link on the bugzilla main page turns into the browserID/text input fields on reload. But that happens in desktop too so I think it's probably a bugzilla thing and unrelated to this issue.
tracking-fennec: --- → ?
Matt - Did we do this on purpose?
Flags: needinfo?(mbrubeck)
If this is happening intermittently, it's probably not by design.

Some details: We initially zoom to fit the viewport width, not the page width (bug 681995).  For many pages these are the same, and the page should initially be zoomed "all the way out" to fit the page width.  But for a page whose contents are wider than the viewport (which is 980px by default), the entire width will not be visible.  The default layout should be the same as a 980px-wide desktop browser window.  Pages that would require horizontal scrolling in that desktop browser will also require it in Fennec.

But since this bug is happening intermittently when reloading the page or restarting Fennec, it's probably not caused by the width of Bugzilla's content exceeding 980px.
Flags: needinfo?(mbrubeck)
QA Contact: general → kbrosnan
Re-nom if we get a regression range and people who can reproduce it.
tracking-fennec: ? → -
I keep running into this while trying to debug bug 803878, so I added some logging to try and figure out why it was happening. Log attached.

At 15:06:55.072, we receive the before-first-paint event in browser.js. We first set the CSS viewport to the default of 980x480, and then do a bunch of calculations in updateViewportSize() to figure what the CSS viewport should actually be. We set it to 980x1412.8333333333333 (at 15:06:55.087) which is correct, check to see if the scale needs to be adjusted to fit the page, and then set the viewport again to 980x1412.8333333333333 (at 15:06:55.095). At this point the zoom is 0.7346938775510204 which is fine.

Then, at 15:06:55.345, we receive a call to GeckoLayerClient.setFirstPaintViewport in Java. The viewport that comes in is this:

v=RectF(0.0, 0.0, 720.0, 1038.0) p=RectF(0.0, 0.0, 529.0, 763.0) c=RectF(0.0, 0.0, 720.0, 1038.0) z=0.734694

This indicates the viewport (in device pixels) is 720x1038, which is correct. However, the page size in CSS pixels (the "c=" rect) is set to 720x1038, instead of the expected 980x1412. At the zoom level of 0.734694, the page is rendered at 529x763 in device pixels (the "p=" rect in the output above). The Java code realizes this will result in overscroll being visible and therefore clamps the zoom level to a min of 1.0. The code that does this is in PanZoomController.getValidViewportMetrics(). This 1.0 zoom then gets propagated all over the place, resulting the final page getting rendered at 1.0 instead of a "fit to width" as expected.

As far as I can tell, the bug here is that the page is rendered at a size that is incorrect. It gets rendered to a CSS pixel size of 720x1038 instead of 980x1412. I assume layout is picking up the 720x1038 from the size of the XUL window instead of using the CSS viewport size.
Moving to Core:Layout based on analysis in comment #6.
Component: Graphics, Panning and Zooming → Layout
Product: Firefox for Android → Core
Also for future reference this is the debug logging I added locally to generate the log in attachment 677537 [details]. The STR are simply to start Fennec and click on the about:home topsite link to http://mozilla.bonardo.net/torino2012/ - it often (but not always) gets rendered at the wrong zoom level on first load.
I'm seeing this when intermittently. Especially on wikipedia if I go back a page. (Firefox 32.0a1)
So I had 76 tabs open, decided to clean up a bunch and as I was going back through the tabs (most from previous sessions), most of them were zoomed in.
Doesn't appear to be an issue for me anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.