Closed Bug 935615 Opened 8 years ago Closed 8 years ago homepage is super zoomed in


(Firefox for Android Graveyard :: Toolbar, defect)

Not set


(firefox25 affected, firefox26- affected, fennec+)

Tracking Status
firefox25 --- affected
firefox26 - affected
fennec + ---


(Reporter: tchung, Assigned: wesj)




(Keywords: regression)


(8 files)

The apple home page is showing up mega zoomed in on Firefox ANdroid.   this seems to scale correctly when launching Chrome.

Affects Fx25 and Fx26.

Html source and screenshot attached.

1) launch Fx26 or fx25 on Nexus 5, Android 4.4  (affects older devices also)
2) goto
3) Verify page is mega zoomed in

- scale page correctly to firefox android

- site loads way zoomed in.
Attached image screenshot
Possibly this snippet.

	<meta name="viewport" content="width=1024, user-scalable=no" />
	<meta name="omni_page" content="Apple - Index/Tab" />
	<meta name="Description" content="Apple designs and creates iPod and iTunes, Mac laptop and desktop computers, the OS X operating system, and the revolutionary iPhone and iPad." />
	<link rel="home" href="" />
	<link rel="alternate" type="application/rss+xml" title="RSS" href="" />
	<link rel="index" href="" />
	<link rel="stylesheet" href="" type="text/css" />
	<link rel="stylesheet" href="" type="text/css" />
	<link rel="stylesheet" href="" type="text/css" />
	<link rel="stylesheet" href="" type="text/css" />
Summary: homepage is super zoomed → homepage is super zoomed in
I'm not entirely sure this is a TE bug, based on what other browsers do. I've tested Chrome, Blink-Opera, Presto-Opera, iOS6 Safari, Firefox, Android native browser.

If "width=1024, user-scalable=no" is set in meta@viewport, the viewport is super zoomed in in Firefox for Android and the Android native browser. All other browsers behave as I would expect.

Here's three testcases:, <meta name="viewport" content="width=1024">, <meta name="viewport" content="width=1024, user-scalable=no">, <meta name="viewport" content="width=1024, user-scalable=yes">

Unfortunately there's no real spec to read, but I would guess that iOS Safari is the reference blackbox^H^H^H^Himplementation. And iOS 6 on my old iPhone shows all 3 testcases with the viewport scaled to 1024 virtual pixels.
Attached image chrome.png
Attached image ff.png
Attached image ios.png
Attached image native.png
Attached image opera.png
Attached image presto.png
The order of the screenshots is 1) width=1024 2) width1024, user-scalable=yes width=1024 3)user-scalable=no.

Also to clarify, the Firefox for Android and Android Native browser aren't quite the same. Fennec is zoomed in somewhere in the middle while the Native browser is zoomed in at the top of the page.
That does sound like a FF bug.
Component: Mobile → Graphics, Panning and Zooming
Product: Tech Evangelism → Firefox for Android
tracking-fennec: --- → ?
A quick investigation shows that since there is no initial-scale set, we default to window.devicePixelRatio as the zoom (2.0 on my Nexus 4), and then while doing the zoom in to that level we use the center of the viewport as the focus so you end up in with a nonzero scroll offset.

If we modify the code at [1] to set the "scale" variable be something more reasonable under these conditions then that should fix this.

I emailed my former colleague Rune (who authored the CSS Device Adaptation spec) asking about sane defaults for zoom and he replied:

On 20/11/2013 14:23, Rune Lillesveen wrote:> There is a non-normative section in the spec suggesting how to pick an
> initial zoom factor when it's auto:
> That description did match the Safari/iOS behavior at the time of
> writing. Perhaps a bit technically written, but in short it means:
> "If the zoom (initial-scale for meta viewport) is 'auto', zoom out as
> far as you can constrained by the min-zoom and not revealing a
> non-rendered area."
> The rendered area is at least as big as the the viewport, but can be
> extended by overflowing content.
> I think Opera/Presto for Android only looked at the width, probably
> Blink/WebKit too. As an example, take a device of 320x480 where you
> set width=device-width. If you add a 400px wide div to the document,
> but the document would not have content to make it taller than 480px,
> Opera/Presto would zoom out to make the whole 400px div visible while
> Safari/iOS would stay at zoom=1 because otherwise an area below the
> 480px height would be become visible. Safari/iOS would zoom to show
> the 400px div if content was added to the document to make the
> vertical overflow tall enough.
Not tracking this since it's visual glitch but has workaround and website functions - also it shipped in FF25 without major user feedback about seeing this on a lot of sites that we know of.  So a low risk uplift would be considered but we're very late in the Beta cycle for speculative fixes and this might have to wait until FF27 unless it's extremely low risk and testable OR if we can find the regression and try a backout to a known-good state.
We don't know that this is a regression. The website could have changed.
Keywords: regression
Assignee: nobody → wjohnston
tracking-fennec: ? → +
Narrowed this to a release using comment 3 testcase 2. I have not been able to reproduce via

Firefox 20 good 
Firefox 21 broken

Firefox 21 development started on 2013-01-07 and ended on 2013-02-19.
Keywords: regression
I tried to find a regression between the interval Kevin mentioned. I was not able to reproduce it. 
I did try with the Fx 26 Release build from Play (26.0.1) and I am not seeing the page zoomed (bug was reported on 25 and 26)
Closed: 8 years ago
Resolution: --- → WORKSFORME
The actual site has changed, it's now just <meta name="viewport" content="width=1024" /> (without user-scalable=no). So I think we still have the bug, just not on the current incarnation of
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.