515424 - on htc touch pro, the mozilla-central builds of fennec maemo are all fuzzy and hard to read

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

installing the latest trunk builds on my htc touch pro (noted originally on Sept 3, further research puts it between aug 30-sept1) I have a very distorted UI.  All elements are fuzzy, there are black lines making a grid out of the web page, and all images and text are FUZZY.

Playing with it more, it appears that we are double sizing everything (chrome images, url bar, etc...

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: sets the pref to "1"

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/mobile-browser/rev/efcb617d1d3d
and then backed out http://hg.mozilla.org/mobile-browser/rev/ebabff172845
because it caused bug 515661

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

This should be fixed by http://hg.mozilla.org/mozilla-central/rev/e4abfec25e38, resolving

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

unfortunately that changeset didn't fix the problem. I'm guessing that the issue is that all.js has a string pref and fennec is defining an int pref. I'll investigate further but for now this needs to be reopened.

Comment 5

[Sylvain Pasche]

If you have a debug build, it would be interesting to set a breakpoint in nsThebesDeviceContext::SetDPI and then:
1) See what value is stored in prefDevPixelsPerCSSPixel after the pref is read. If the pref is set to 1 (int) or "1" (int), it should store 1.0(float) in that variable.

2) in the end of the method, what's the value of:
            mAppUnitsPerDevNotScaledPixel =
                PR_MAX(1, static_cast<PRInt32>(AppUnitsPerCSSPixel() /
                                               prefDevPixelsPerCSSPixel));

In theory when the pref is 1 or "1", prefDevPixelsPerCSSPixel is 1.0f, so mAppUnitsPerDevNotScaledPixel should be max(1, (int)(60 / 1.0f)) -> 60. But maybe there could be something wrong.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

It seems that once a pref is set, we can't change its type.  So since we set it in all.js as a string, setting it in fennec's mobile.js to an int makes the pref an empty string ("").

removing it from all.js doesn't help much either.  Once we try to look at it it seems it becomes an int pref, which is fine as long as we set it as an int.  But if mobile.js tries to set it as a string after that we get a very large somewhat random number.

I'm not sure what can be done at this point other than making our pref system handle this situation better.

Comment 7

[Sylvain Pasche]

Or land bug 513439 and bug 515455 on branch and then use a string everywhere?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, I think we should just land Sylvain's patches on branch and use a string everywhere.

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

this is the case on 1.9.2 branch.  Please fix as this is a major regression.

Comment 10

[Sylvain Pasche]

Now that bug 513439 has landed on branch and trunk, the patch in attachment 399514 [details] [diff] [review] should be checked in again (it was backed out) and this issue will be fixed.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #10)
> Now that bug 513439 has landed on branch and trunk, the patch in attachment
> 399514 [details] should be checked in again (it was backed out) and this issue will be
> fixed.

OK. I can land it again.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
https://hg.mozilla.org/mobile-browser/rev/19776a27c8f2

Comment 13

[Aakash Desai [:aakashd]]

No fuzzies on build:

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.2a2pre) Gecko/20090922
Fennec/1.0b4pre