Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Fennec reports wrong screen resolution/density and pixel ratio

RESOLVED FIXED

Status

()

Firefox for Android
General
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: lucasr, Assigned: mbrubeck)

Tracking

({regression})

16 Branch
All
Android
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16+ fixed, firefox17 fixed, firefox18 verified, fennec16+)

Details

(Whiteboard: [leave open])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
Because of that, media queries with min-resolution and -moz-device-pixel-ratio just don't work. This is happening on current Aurora and Nightly. I've created two test pages to help us finding out when the regression happened. The page should show the correct Android density on screen (MDPI, HDPI, and XHDPI).

Test min-resolution media query
http://lucasr.org/res.html

Test -moz-device-pixel-ratio media query
http://lucasr.org/pix.html
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ec41fa92504f&tochange=5a372bbee65c

Looks like bug 741644, bug 662061, bug 771390
Adding dbaron
(Reporter)

Comment 3

5 years ago
This seems to be a very serious regression btw. Pixel ratio is always 1.0 even on HDPI and XHDPI Android devices. Pretty much breaks any media queries using screen density conditions.
(Reporter)

Updated

5 years ago
Blocks: 776903

Updated

5 years ago
tracking-fennec: --- → ?
status-firefox16: --- → affected
status-firefox17: --- → affected
(Reporter)

Updated

5 years ago
Duplicate of this bug: 776903
Bug 771390 should have changed resolution, but they shouldn't have changed anything about -moz-device-pixel-ratio.  They should have made resolution work the same way device-pixel-ratio does, except for the factor of 96.

Are you sure device-pixel-ratio changed in that range?  If so, which changeset changed it?
And I'm not sure when we'd ever have returned non-integer values for device-pixel-ratio.  I thought it should always be an integer.
(Reporter)

Comment 7

5 years ago
(In reply to David Baron [:dbaron] from comment #6)
> And I'm not sure when we'd ever have returned non-integer values for
> device-pixel-ratio.  I thought it should always be an integer.

Not if we want to be compatible with -webkit-device-pixel-ratio. For example, here's what Android does:

  http://developer.android.com/guide/webapps/targeting.html#DensityCSS

Even if it was integer-only, I'm seeing -moz-device-pixel-ratio == 1 on an XHDPI device where it should be 2.
(Reporter)

Comment 8

5 years ago
(In reply to David Baron [:dbaron] from comment #5)
> Bug 771390 should have changed resolution, but they shouldn't have changed
> anything about -moz-device-pixel-ratio.  They should have made resolution
> work the same way device-pixel-ratio does, except for the factor of 96.
> 
> Are you sure device-pixel-ratio changed in that range?  If so, which
> changeset changed it?

So, you mean we should use things like (-min-resolution: 2) meaning the device has screen density (2 * 96dpi)?
On xhdpi devices length of independent by width is 360. So chrome scales viewport into ~340 pixels and has ~2.14 dpr. Opera scales to 320 and has ~2.25 dpr. If you want has exactly 2 into dpr (or resolution: 2dppx) you should scale page to 360 pixels when developer adds meta tag or style with viewport with zoom value -- 1.
Duplicate of this bug: 780999
(Reporter)

Comment 11

5 years ago
(In reply to Arthur from comment #9)
> On xhdpi devices length of independent by width is 360. So chrome scales
> viewport into ~340 pixels and has ~2.14 dpr. Opera scales to 320 and has
> ~2.25 dpr. If you want has exactly 2 into dpr (or resolution: 2dppx) you
> should scale page to 360 pixels when developer adds meta tag or style with
> viewport with zoom value -- 1.

I'm using (min--moz-device-pixel-ratio: 2.0) and still doesn't work. Using (min-resolution: 2dppx) doesn't work either (on XHDPI devices).
Yep, it seems latest versions has bug here. But Firefox Stable still matches 320+ dpi and 2dppx.
(Assignee)

Updated

5 years ago
tracking-firefox16: --- → ?
Keywords: regression
tracking-fennec: ? → 16+
(Assignee)

Comment 13

5 years ago
On my HDPI Android device, I get the following values in GetResolution:

a: AppUnitsPerPhysicalInch = 14400
b: AppUnitsPerCSSInch = 5760
c: AppUnitsPerDevPixel = 60

GetResolution used to return a/c = 240, but the patch from bug 771390 changed it to return b/c = 96.

AppUnitsPerCSSInch is always defined as (96 * AppUnitsPerCSSPixel) = (96 * 60).

AppUnitsPerDevPixel is set to mAppUnitsPerDevNotScaledPixel / mPixelScale, which is currently set to (60 / 1.0) = 60.  Is this the value that we ultimately need to change, to more accurately reflect how we do layout and zooming on Android?  There are currently some prefs or widget methods that can change this, but they seem designed for use with FullZoom and have side effects that we don't want...
It's also possible that we just need to teach some of these media queries to better reflect the state of the device rather than the state of the fake viewport in which we're doing mobile rendering.  The question is which ones and how -- since that does break the viewport + pan + zoom model.
(Assignee)

Updated

5 years ago
Blocks: 771390
OS: Linux → Android
Hardware: x86 → All
Version: unspecified → Firefox 16
(Assignee)

Comment 15

5 years ago
(In reply to David Baron [:dbaron] from comment #14)
> It's also possible that we just need to teach some of these media queries to
> better reflect the state of the device rather than the state of the fake
> viewport in which we're doing mobile rendering.  The question is which ones
> and how -- since that does break the viewport + pan + zoom model.

I think the "resolution" media query should definitely reflect the state of the physical device; this would match the existing behavior of Fennec and other browsers, and the spec says it should be "the resolution of the output device."
tracking-firefox16: ? → +
(Assignee)

Updated

5 years ago
Blocks: 564815
(Assignee)

Comment 16

5 years ago
dbaron, should we back out bug 771390 (at least on Aurora) to fix this regression?  Is there a simple fix to make "resolution" always report the device resolution, as suggested in comment 14?
(Assignee)

Comment 17

5 years ago
I think the correct dppx value on Android (i.e. the one that matches other mobile browsers with panning/zooming independant of the CSS viewport) is the value returned by ViewportHandler.getScaleRatio in the Android front-end:
https://hg.mozilla.org/mozilla-central/file/f9a8fdb08193/mobile/android/chrome/content/browser.js#l4579

Perhaps the best solution is to finish moving this code into Gecko (bug 716575) and then make the resolution media query aware of it.  I can work on this, but I'll need some advice from dbaron or other layout/content experts to figure out the right way to do it.  We still need a lower-risk fix for Fx16 (and probably Fx17), e.g. backing out bug 771390.
Summary: Fennec reports wrong screen density and pixel ratio → Fennec reports wrong screen resolution/density and pixel ratio
(Assignee)

Comment 18

5 years ago
(In reply to David Baron [:dbaron] from comment #5)
> Bug 771390 should have changed resolution, but they shouldn't have changed
> anything about -moz-device-pixel-ratio.  They should have made resolution
> work the same way device-pixel-ratio does, except for the factor of 96.

It looks like this is accurate.

* Before bug 771390 was fixed, resolution had a correct value on Android, while device-pixel-ratio was broken on Android and always had a value of 1.

* After bug 771390 was fixed, device-pixel-ratio is unchanged (still broken), and resolution now always has a value of 96dpi (1dppx), which matches the broken device-pixel-ratio behavior.

This is regressing in-content UI in Firefox 16 that uses the "resolution" media query (bug 776903).

Updated

5 years ago
Duplicate of this bug: 784802
(Assignee)

Comment 20

5 years ago
Created attachment 654770 [details] [diff] [review]
band-aid

Here's a band-aid patch that might be suitable for Fx16 and 17.  Basically this reverts to the old behavior on Android, while keeping the bug 771390 fix on desktop platforms.

Longer-term, I think the real fix for overridden viewports will be to change both resolution and device-pixel-ratio aware of the nsContentUtils::GetDevicePixelRatio code in the patches for bug 716575.
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
Attachment #654770 - Flags: feedback?(dbaron)

Updated

5 years ago
Duplicate of this bug: 785285
(Assignee)

Comment 22

5 years ago
Created attachment 656225 [details] [diff] [review]
band-aid (v2)

Also revert the test changes from bug 771390 because they will fail on HDPI Android devices, and I think they are incorrect in general per comment 7.  Pushed to Try: https://tbpl.mozilla.org/?tree=Try&rev=66c98e4fe62f
Attachment #654770 - Attachment is obsolete: true
Attachment #654770 - Flags: feedback?(dbaron)
Attachment #656225 - Flags: review?(dbaron)
(Assignee)

Comment 23

5 years ago
Created attachment 656237 [details] [diff] [review]
WIP

This is a sketch of what a "real" fix would look like.  This brings Android (and any other platform using viewport overrides) back in line with the spec changes implemented in bug 771390.  It depends on the patches in bug 716575 which aren't fully reviewed yet.
Attachment #656237 - Flags: feedback?(dbaron)
(Assignee)

Comment 24

5 years ago
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

It looks like this broke Android reftests on Try.  Investigating.
Attachment #656225 - Flags: review?(dbaron)
(Assignee)

Comment 25

5 years ago
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

False alarm; the Android R1 oranges were from a bad patch that I pushed on top of.  Here's a Try run with green R1 tests: https://tbpl.mozilla.org/?tree=Try&rev=0a8aee25e69e
Attachment #656225 - Flags: review?(dbaron)
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

r=dbaron as a temporary fix
Attachment #656225 - Flags: review?(dbaron) → review+
Comment on attachment 656237 [details] [diff] [review]
WIP

This patch is exactly the same as the other one.  Did you mean to attach WIP for the permanent fix?
Attachment #656237 - Flags: feedback?(dbaron)
(Assignee)

Comment 28

5 years ago
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

https://hg.mozilla.org/integration/mozilla-inbound/rev/e7d3b0866dd9
Attachment #656225 - Flags: checkin+
(Assignee)

Updated

5 years ago
Whiteboard: [leave open]
(Assignee)

Comment 29

5 years ago
Created attachment 657427 [details] [diff] [review]
WIP 2

Sorry, here's the correct WIP patch.
Attachment #656237 - Attachment is obsolete: true
Attachment #657427 - Flags: feedback?(dbaron)
https://hg.mozilla.org/mozilla-central/rev/e7d3b0866dd9
(Assignee)

Comment 31

5 years ago
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 771390

User impact if declined: "resolution" media query gives incorrect result on high-DPI Android devices.  (This is a web-facing regression that breaks existing web content, as well as some of Fennec's own in-content UI.)

Testing completed (on m-c, etc.): On m-c since 8/31.  The code this touches has good automated test coverage.

Risk to taking this patch (and alternatives if risky): This is a fairly low-risk patch that should have no effect on desktop Firefox.  On mobile Firefox it just reverts the change made by bug 771390.

String or UUID changes made by this patch: None.
Attachment #656225 - Flags: approval-mozilla-beta?
Attachment #656225 - Flags: approval-mozilla-aurora?
Comment on attachment 656225 [details] [diff] [review]
band-aid (v2)

[Triage Comment]
Fix for a new FF16 issue, returning us to a known good state.
Attachment #656225 - Flags: approval-mozilla-beta?
Attachment #656225 - Flags: approval-mozilla-beta+
Attachment #656225 - Flags: approval-mozilla-aurora?
Attachment #656225 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 33

5 years ago
Landed on beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/ae36fddd9e3f

Will land on Aurora when the Aurora tree re-opens.
status-firefox16: affected → fixed
Thus far glanced over the reader-mode toolbar on the Galaxy Nexus and the drawables are much crisper now.

Comment #0's URLs:

Galaxy Nexus's reported min-resolution media query: XHDPI
Galaxy Nexus's reported -moz-device-pixel-ratio media query: MDPI
status-firefox18: --- → verified
(Assignee)

Comment 35

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/ecd964c8edec
status-firefox17: affected → fixed
Comment on attachment 657427 [details] [diff] [review]
WIP 2

So it would be helpful to have comments here explaining what you intend resolution and device-pixel-ratio to mean when the viewport is overridden.  Presumably they ought to describe the behavior you get with width=device-width or similar patterns, no?

I'm puzzled by the code, though -- it seems like you're doing different things for resolution and device-pixel-ratio -- for one you're multiplying by GetDevicePixelRatio, and for the other you're replacing the other value with it.  I'd expect the same answer for both (not sure which).

Otherwise the approach seems good, though.

Also, you can probably re-remove the appUnitsPerInch variable in GetResolution.
Attachment #657427 - Flags: feedback?(dbaron) → feedback-
(Assignee)

Updated

5 years ago
Blocks: 794056
(Assignee)

Comment 37

5 years ago
I think the right way to solve this may involve changing nsIWidget::GetDefaultScale as discussed in bug 716575 comment 33 and 34.
Matt - Can we file a new bug on the remaining work?
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Depends on: 803207
(Assignee)

Comment 39

5 years ago
Filed follow-up bug 803207.
(Assignee)

Updated

5 years ago
Blocks: 840916
You need to log in before you can comment on or make changes to this bug.