Full page screenshots are scaled down without warning
Categories
(Firefox :: Screenshots, defect, P3)
Tracking
()
People
(Reporter: heavymetal, Assigned: niklas)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
Take a full page screenshot in Firefox on Windows or Linux desktop with Firefox' builtin screenshot tool.
Actual results:
Image is scaled down to 2552 px width, and it's scaled down BADLY without any antialiasing. Whole table lines are dropped because of their 1 px width, that type of "scaling" simply doesn't work for websites.
Expected results:
Full page screenshots should NEVER get scaled down, they should capture unscaled images as the screenshot tools does for "visible area only".
At least there should be a big fat warning that the screenshot just taken will probably be useless.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Screenshots' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
Could you please provide a screenshot with what you are facing just to make it easier for me to understand the issue?
Thanks.
Reporter | ||
Comment 3•4 years ago
|
||
Reporter | ||
Comment 4•4 years ago
|
||
Both screenshots taken from the same Bugzilla page.
Full page is automatically scaled down and some horizontal lines are dropped.
Visible area screenshot is not scaled down.
Reporter | ||
Comment 5•4 years ago
|
||
I just noticed: When opening these files in Firefox, they both get zoomed in. The downscaled "full" screenshot (2560 px) shows as fullscreen on my 3840 px screen, the "visible area" screenshot (3840 px) is presented at zoom level 66% to fill the screen, zooming in to 100% makes the image too large to fit on the screen.
So maybe a scaling issue caused by the environment's dpi setting?
I think screenshots should always reflect the actual screen rendering, at least they should scale consistently for full and partial screenshots.
Thanks for taking a look at the issue.
Comment 6•4 years ago
|
||
Managed to reproduce this issue on Windows 10 x64 and on Ubuntu 20.04 x64.
Assignee | ||
Comment 7•4 years ago
|
||
Hey Hani, can you share the device pixel ratio and screen resolution of the devices you were able to reproduce this on?
Comment 8•4 years ago
|
||
Pixel ratio: 16:9
Screen resolution: 1920 x 1080
Please let me know if I can help with other info.
Comment 9•4 years ago
|
||
(In reply to Hani Yacoub from comment #8)
Pixel ratio: 16:9
We actually need the value of window.devicePixelRatio
from your devtools console. I should be 1 for a regular display and > 1 for high-pixel-density displays. Also, can you check your OS scaling settings - are those at 100% or more?
Reporter | ||
Comment 10•4 years ago
|
||
My screen is 3840x2160, window.devicePixelRatio is 1.5 in both Windows and Linux, default zoom in Firefox is 100%.
In Linux, environment is set to 160 dpi via parameter Xft.dpi in ~/.Xresources, because Firefox ignores the correct dpi setting recognized by the X Server (as verified via xdpyinfo).
In Windows, display scaling is set to 150%.
Comment 11•4 years ago
|
||
On Windows:
Screen resolution: 1920 x 1080
Pixel ratio: 1.25
Scaling is 125% (Recommended)
On Ubuntu:
Screen resolution: 1920x1080 (16:9)
Pixel ration: 1
Scale: 100%
Comment 12•3 years ago
|
||
In the past reducing file size was a constraint Screenshots needed to work with, I think now that screenshots is entirely client-side, people should get what they see and can downsize afterwards if they need to.
Assignee | ||
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 17•3 years ago
|
||
The patch landed in nightly and beta is affected.
:niklas, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
I managed to reproduce this on Firefox 100.0(20220428192727) on Win10 64-bits. Verified as fixed on Firefox 101.0b7(20220515185854), Nightly 102.0a1(20220515214519) on Win10 64-bits, Ubuntu 20.04 and macOS 11.
Description
•