429439 - window.innerWidth/innerHeight/outerWidth/outerHeight skewed to high side when HTML page loaded from chrome: URL

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Attachment: testcase demonstrating problem

When I load an HTML page from a chrome: URL, the values for the window.innerWidth/innerHeight/outerWidth/outerHeight properties are skewed to the high side.  The same HTML page loaded from a file: URL has correct values for those properties.

For example, on my 1920x1200 resolution monitor, with a maximized browser window, when the attached testcase is loaded from a file: URL, innerWidth/innerHeight is 1920/976, while outerWidth/outerHeight is 1920/1125, which are reasonable values for those properties.

But when the testcase is loaded from a chrome: URL, innerWidth/innerHeight is 2368/1204, and outerWidth/outerHeight is 2368/1388.

document.body.clientWidth is similarly skewed, reporting 1904 from file: and 2352 from chrome:.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

window.getComputedStyle(document.documentElement, null).width has the same problem.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Tests at various sizes show that the skewed values are proportional to the correct values with a constant of proportionality of 1.23.

Comment 3

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

That is a bit strange.

Can you set a breakpoint on nsGlobalWindow::GetInnerWidth and tell me what you get for 'width' and presContext->DevPixelsToAppUnits(width)?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #3)
> That is a bit strange.

It gets stranger.  I only see this behavior on one profile, and only when test.html is loaded from an extension's chrome.  The same exact file reports correct values when loaded from the browser's chrome or when loaded from the extension's chrome in a different profile.


> Can you set a breakpoint on nsGlobalWindow::GetInnerWidth and tell me what you
> get for 'width' and presContext->DevPixelsToAppUnits(width)?

width is always the correct value (1920, the width of my 1920x1200 monitor), and presContext->DevPixelsToAppUnits(width) is normally 115200, but it's 142080 when the problem occurs.

Comment 5

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

So that's 74 appunits per dev pixel. Is that extension doing something with fullzoom? That's the only way I can think of that would make allow appunits to take that value when you're not printing or in print preview. You wrote the browser-fullZoom code, were you playing with it in that extension?

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #5)
> So that's 74 appunits per dev pixel. Is that extension doing something with
> fullzoom? That's the only way I can think of that would make allow appunits to
> take that value when you're not printing or in print preview. You wrote the
> browser-fullZoom code, were you playing with it in that extension?

The extension doesn't do anything with fullzoom, but since you mentioned it, I tested changing the zoom on the test page, and that indeed causes innerWidth to change, and it happens consistently across profiles and chrome locations.

In fact, it happens on content pages, too.  Just load attachment 316149 [details], zoom out twice, and reload to see innerWidth reported as 2368.

Comment 7

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

fullZoom is *supposed* to cause innerWidth to change.

So is fullZoom being applied in the original testcase you reported here?

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #7)
> fullZoom is *supposed* to cause innerWidth to change.

Ah, I didn't realize that.


> So is fullZoom being applied in the original testcase you reported here?

Yes, fullZoom was being applied.  Once I reset it, the problem goes away.  So, since this is intended behavior, resolving this bug as invalid.