Example document http://ww1.microchip.com/downloads/en/DeviceDoc/51953A.pdf Expected: When scrolling down I expect to not be able to scroll further down than just this one page document. Actual: It seems like there is an extra invisible page under the one page.

FWIW, this is WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130105 Firefox/20.0 ID:20130105030839 with PDF Viewer 0.7.45.

WFM me as well. What version of Firefox are you using?

WFM also with latest Nightly. Stefan, do you still see the issue?

(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #3) > WFM also with latest Nightly. > Stefan, do you still see the issue? Yes. Still same issue on Nightly. I forgot to mention one thing that I realize might be important: I'm on a Retina MacBook Pro. Is it possible that this only happens on that hardware?

(In reply to Stefan Arentz [:st3fan] from comment #4) > (In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #3) > > WFM also with latest Nightly. > > Stefan, do you still see the issue? > > Yes. Still same issue on Nightly. > > I forgot to mention one thing that I realize might be important: I'm on a > Retina MacBook Pro. Is it possible that this only happens on that hardware? Can you please try with a new profile ( http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) or in safe mode ( http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode#w_how-to-start-firefox-in-safe-mode ) and see if it still reproduces?

Yes, same issue on a clean profile.

I am unable to reproduce this with Firefox 19.0b5 though I'm not on a retina Mac. That may make a difference. I'll try to find someone with a retina Mac to confirm.

Using Retina MacBook Pro, I can reproduce. Issue occurs in both nightly 2013-02-07 and 19.0b5. For comparison, I used nightly on an Ubuntu image, to see the difference. If need be, I can take a video screenshot to demonstrate the visual behavior.

FWIW This still happens for me with today's nightly. Right now I am looking at for example this document: http://media.pragprog.com/titles/mbfpp/tail.pdf

Replicated on Windows 7 Nightly 23.0a1 (2013-04-02) with the example PDFs. There's one page-height of blank space below the document. Please make it block Bug 820679 and change platform to All.

For Win 7, the regression is bug 844604.

Starting with bdahl, unless we think that jfkthame's help is needed here.

Pinged Brendan about this, not a lot of time to address in FF22.

Just a quick message that this bug is still present in Nightly as of 23-May-2013

I'll try to check it out Tuesday when I can get a high dpi mac. However, I think this is somewhat low priority due to the problem it causes and how many people have high dpi screens.

If you have a 2560x1xxx screen kicking around, you can set hiDPI on that with SwitchResX. (or on Windows out of the box in the resolution control panel) On Windows you could also try 1920x1200 @ 144dpi. (but you'll love the rMBP ;))

(In reply to Brendan Dahl from comment #16) > I'll try to check it out Tuesday when I can get a high dpi mac. However, I > think this is somewhat low priority due to the problem it causes and how > many people have high dpi screens. Agreed that we can ship without, but would rather now. The thinking behind tracking this bug is that FF22 is the first Firefox version to properly support Windows HiDPI.

// sorry for the spam, posted this in the duplicate bug... On highdpi screens we create an extra large canvas and then scale the canvas down with a css transforms to improve the quality. The extra space is due to the handling of the scaling and calculating heights. I'm not exactly sure what the correct handling of this is since IE/Chrome/Firefox all have different results for the attachment (a highdpi screen is NOT needed to see the issues). As a temporary workaround we can probably wrap the canvas in a div and hide the overflow, but we may want to investigate how this should be properly handled in another bug. I'll look into this tomorrow.

hiDPI vs. Canvas is something that needs to be thought through more thoroughly and deserves its own bug. I think something akin to backingScaleFactor for canvases makes the most sense.

Try build https://tbpl.mozilla.org/?tree=Try&rev=8020739e5ea4

Comment on attachment 757489 [details] [diff] [review] aurora patch [Approval Request Comment] Bug caused by (feature/regressing bug #): n/a User impact if declined: Extra space after pdf pages for users with hidpi screens. Testing completed (on m-c, etc.): in the pdf.js developer extension for over a week Risk to taking this patch (and alternatives if risky): low, mainly css and html changes for content permission code String or IDL/UUID changes made by this patch: none

Comment on attachment 757490 [details] [diff] [review] beta patch [Approval Request Comment] Bug caused by (feature/regressing bug #): n/a User impact if declined: Extra space after pdf pages for users with hidpi screens. Testing completed (on m-c, etc.): in the pdf.js developer extension for over a week Risk to taking this patch (and alternatives if risky): low, mainly css and html changes for content permission code String or IDL/UUID changes made by this patch: none

What I talk about in comment #20 is actually covered in Bug 780362. My apologies.

https://hg.mozilla.org/releases/mozilla-aurora/rev/1504352b0676 https://hg.mozilla.org/releases/mozilla-beta/rev/d0a27a8a2ccd Fixed on trunk by bug 878897.

This doesn't appear to be fixed. I've tried FF23.0b4 from 2013-07-08 and FF24 from 2013-07-16. The space is still there, and it looks identical to the shipping version of FF22. Happy to help diagnose this further, if possible.

If this isn't fixed on 24, please revert the status-firefox24 flag to affected and add any other development branches this still occurs on.

FF24 candidate looks A-OK.