996563 - Font inflation is not re-run when screen size and density changes

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Toolbar, defect, P5)

Description

[Martin Giger [:freaktechnik]]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140410030200

Steps to reproduce:

1. Load a Website in Firefox for Android on a Device with a changeable screen size and pixel density
2. Change screen size & density
3. Open a new tab and load a website

In a real live scenario, you could do this with an Asus PadFone (in my case an Infinity 2). To get the results I get you need to perform an additional perparation step before executing the steps described above:
Go to the "Dynamic display switch list" setting of the PadFone (ASUS customized settings -> PadFone Settings) and check Firefox.


Actual results:

When the screen size changes and and a new website is loaded, it still renders it for the previous screen size and density.


Expected results:

The website should have rendered with the new screen size and density.

Comment 1

[Aaron Train [:aaronmt]]

Do you have a particular site you are witnessing this on? Which version of Firefox are you using?

Comment 2

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

If the device is changing screen properties while Firefox is running then we will likely not respond properly. I'm pretty sure we read a lot of those properties on startup and assume they don't change.

Comment 3

[Martin Giger [:freaktechnik]]

(In reply to Aaron Train [:aaronmt] from comment #1)
> Do you have a particular site you are witnessing this on?
Any website, as the dpi value changes, so the css pixel to screen pixel ratio changes.
> Which version of Firefox are you using?
As indicated on 28, to be exact on 28.0.1

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)
> If the device is changing screen properties while Firefox is running then we
> will likely not respond properly. I'm pretty sure we read a lot of those
> properties on startup and assume they don't change.
Well, the toolbar changes its style (I guess that's android doing that), it's just the browser view. And sadly there are devices that can change their screen properties. I believe all padfones send the rotate and viewsize change events or similar (it is impossible to find this documentation these days), so it would probably be enough to re-read these values when view changing events are fired. Again, I don't know how those events are called and which ones they are, I am not too familar with Android. If I can find the documentation on how the PadFones do their screen size change handling, I'll post it here.

Comment 4

[Martin Giger [:freaktechnik]]

The specification for DynamicDisplay Switching can be found here: http://dlcdnet.asus.com/pub/ASUS/Mobile_Phone/PadFone/Padfone_9_0_0_1_Emulator_system_img.rar

Comment 5

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

Sorry, I should have responded earlier. A couple of things:
1) this should probably go through Fennec triage to see where it stacks up in our priority list because it looks non-trivial to fix. I'm setting the tracking flag on this bug so that we get a sense of how important it is.
2) If we are going to attempt fixing it ourselves then we'll need to get a hold of devices that can reproduce this issue. Aaron, I don't know if you have some in the office but I don't have any with me.

Comment 6

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

Kats, could you mentor this bug?

Comment 7

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

Maybe for an advanced contributor. Honestly I don't know what all would need to change here, but I can probably guide somebody through debugging the problems and figuring out solutions. It's likely to be nontrivial to fix. They would also need to have a device that can reproduce the problem, as I do not.

Martin, if you could attach screenshot showing the expected and actual results that would probably help as well.

Comment 8

[Martin Giger [:freaktechnik]]

Attachment: Actual result when coming from tablet 1

Comment 9

[Martin Giger [:freaktechnik]]

Attachment: Actual result on phone when coming from tablet 2

Comment 10

[Martin Giger [:freaktechnik]]

Attachment: Normal appearance on phone

Comment 11

[Martin Giger [:freaktechnik]]

Attachment: Actual result on tablet when switching from phone 1

Comment 12

[Martin Giger [:freaktechnik]]

Attachment: Actual result on tablet when switching from phone 2

Comment 13

[Martin Giger [:freaktechnik]]

Attachment: Normal appearance on tablet

Comment 14

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

It looks to me that the "normal" and "actual" appearances are only different because of font inflation. Specifically, the phone version is normally inflated more, but isn't inflated when coming from tablet. And the tablet version isn't normally inflated more, but it is when coming from the phone.

The reason I think it's font inflation is because some pieces of text are clearly still the same size, for example the "Bugzilla@Mozilla" text in the top-left corner. If it were DPI problems or some other fundamental scaling problem then everything would be scaled by the same amount.

So I think the solution here is just to make sure the font-inflation code is re-run when the change happens. Looking through the code I think it's meant to happen (specifically triggered from [1]) but maybe it's not?

[1] http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp?rev=01c062964d20#3510

Comment 15

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

Oh, and I'm not sure what's up with the tab switcher as shown in attachment 8427312 [details]. That's on the Java UI side, not the gecko side of things.

Comment 16

[Mark Capella [:capella]]

fwiw - I saw that once and was too surprised to screenshoot, and have never repeated it ... is there STR?

Comment 17

[Martin Giger [:freaktechnik]]

Well, apparently the Java UI side fo things doesn't correctly reposition elements (not only the tabswitcher, but the refreshbutton too) on screen size change.(In reply to Kartikaya Gupta (email:[e-mail]) from comment #14)
> It looks to me that the "normal" and "actual" appearances are only different
> because of font inflation. Specifically, the phone version is normally
> inflated more, but isn't inflated when coming from tablet. And the tablet
> version isn't normally inflated more, but it is when coming from the phone.
> 
> The reason I think it's font inflation is because some pieces of text are
> clearly still the same size, for example the "Bugzilla@Mozilla" text in the
> top-left corner. If it were DPI problems or some other fundamental scaling
> problem then everything would be scaled by the same amount.
> 
> So I think the solution here is just to make sure the font-inflation code is
> re-run when the change happens. Looking through the code I think it's meant
> to happen (specifically triggered from [1]) but maybe it's not?
> 
> [1]
> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.
> cpp?rev=01c062964d20#3510

Well, apparently the Java UI side fo things doesn't correctly reposition elements (not only the tabswitcher, but the refreshbutton too) on screen size change.

(In reply to Mark Capella [:capella] from comment #16)
> fwiw - I saw that once and was too surprised to screenshoot, and have never
> repeated it ... is there STR?
See my first comment. To change screen size and resolution with a PadFone you simple remove/insert the phone from/into the station.

Comment 18

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

(In reply to Martin Giger from comment #17)
> 
> Well, apparently the Java UI side fo things doesn't correctly reposition
> elements (not only the tabswitcher, but the refreshbutton too) on screen
> size change.

It would be good to file a separate bug for this, in the "Theme and Visual Design" component of the "Firefox for Android" product, since it will require a fix that is independent of the font inflation stuff.

Comment 19

[Martin Giger [:freaktechnik]]

Not sure if this is related or not, but css @media queries with width conditions are not rechecked either. So it is probably the code invoking these things that isn't being run.

Comment 20

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

filter on [mass-p5]

Comment 21

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

Font inflation has been disabled, closing this bug.