936984 - Websites appear zoomed once moved into split screen mode (Win 8.1 Metro)

Status: RESOLVED DUPLICATE of bug 937896

(Firefox for Metro Graveyard :: Browser, defect)

Description

[Kamil Jozwiak [:kjozwiak]]

Attachment: Website appearing zoomed while in split screen mode

When moving Firefox Metro into split screen in Windows 8.1, the website will appear as zoomed in.

- Attached a screenshot to illustrate the issue

Steps to reproduce the issue:

1) Open Firefox Metro
2) Go to any website (used Google, Wikipedia, Facebook, Twitter)
3) Once the website has been loaded, drag the desktop from the left hand side and "snap it" into split screen mode. You'll notice that the website will appear zoomed in.

Current Behavior:

- Moving Firefox Metro into split screen mode in Windows 8.1 will show the website as zoomed in

Expected behavior:

- Website(s) shouldn't appear as zoomed in when moving Firefox Metro into split screen mode

Issue was found using the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-11-10-03-02-05-mozilla-central/

Comment 1

[Jim Mathies [:jimm]]

reproducible.

Comment 2

[Jim Mathies [:jimm]]

Also:

1) zoom out in the browser
2) slide the other panel out so that the browser fills the screen

result: page is painted really small, and compressed to one side of the screen, with remaining space filled with black.

Comment 3

[Jim Mathies [:jimm]]

I'm going to try to fix up resizing over in bug 936984.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #3)
> I'm going to try to fix up resizing over in bug 936984.

bah, wrong bug.

Comment 5

[Jim Mathies [:jimm]]

Hmm, logging our resizing, we seem to be getting the correct notifications. So this looks like a bug on apzc / layout.

Comment 6

[Kamil Jozwiak [:kjozwiak]]

Jim, I ran into the issue you described in comment #2 a few times as well! Didn't create a new ticket as I found another bug that had a similar issue (had a few screenshots of the same display problem)

Comment 7

[Marco Mucci [:MarcoM]]

Hey Jim, are you taking this defect during the iteration?  If so, can you provide a point value.

Comment 8

[Jim Mathies [:jimm]]

(In reply to Marco Mucci [:MarcoM] from comment #7)
> Hey Jim, are you taking this defect during the iteration?  If so, can you
> provide a point value.

this is really just another work item under the apzc story.

Comment 9

[Jim Mathies [:jimm]]

Interesting bug. Basically what happens:

1) widget gets the os level resize event, calls the resize method on the widget listener and invalidates the window [1].
2) a os level paint request comes in and widget triggers a paint [1].
3) view manager calls ProcessPendingUpdates() which calls into PresShell:
  ProcessPendingUpdates->
  PresShell::WillPaint->
  PresShell::FlushPendingNotifications->
  PresShell::FireResizeEvent()
4) the dom resize event gets picked up by front end chrome, triggers a change in the UI, which triggers a reflow
5) PresShell::RenderDocument get called which ends up in nsDisplayList::PaintRoot

in here, we calculate the frame metrics data we'll hand over to the compositor. In this frame metrics we get the old viewport dims (from layout), with the new composition rect dims (from widget). When that propagates out to the apzc, we mistakenly change the resolution [2].

[1] http://mxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroWidget.cpp#1171
[2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#1289

Comment 10

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

Hah, Botond was just looking at that code in another context and also determined it was wrong.