1643719 - Full screenshot of pages where a child element is scrollable produce a truncated screenshot

Status: NEW

(Firefox :: Screenshots, defect, P3)

Description

[haswellready]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Whenever I try to make a full screenshot of gmail I get a screenshot of a visible part only.
There are two test cases:

1. from gmail: https://youtu.be/2RFysYZywWU
2. from a downloaded letter: https://youtu.be/lJJtFGXkB28

I've tried the second case because I thought that a downloaded letter will be easier for Firefox to handle with since there is no any toolbars, menues and other elements on a web page.
But it didn't help.

Actual results:

• screenshot is truncated. I get only visible part of screenshot.

Expected results:

• screeshot is full. I get screenshot with a long vertical scrollbar.

Comment 1

[Jeronimo Torti (Please send NI request to Brindusa Tot)]

Hi,
thanks for the details. I was able to reproduce on Windows 10, with Firefox Nightly 80.0a1 (2020-07-06) (64-bit) and Release version 78.0.1 (64-bit).

I've chosen a component so that the issue is reviewed. If it is not the correct component please feel free to change it to an appropriate one.

Regards,
Jerónimo.

Comment 2

[Emma Malysz]

Thanks for reporting this!

Comment 3

[jscher2000]

This is a somewhat common situation: the body height is fixed and scrolling on the body element is disabled. The page has created a scrollable region, but Firefox Screenshot does not modify the page so that the entire contents of the scrollable region can be captured in one shot. I don't know whether it is practical to try to add that functionality.

Fortunately, on Gmail, and other webmail sites, you can click the print button to open a new window/tab with a flat view of the message more suited to printing or (after you cancel the print overlay) for screen capturing.

Comment 4

[Sam Foster [:sfoster] (he/him)]

I'm adjusting the bug title here as we see this on a lot of sites which set body/html overflow:hidden and use a child element as the primary scrollable content area.

Comment 8

[rdz_bug]

Is this bug the reason why the full page screenshot doesn't on this site here?

https://www.cnj.jus.br/pjecnj/ConsultaPublica/DetalheProcessoConsultaPublica/listView.seam?ca=7b9d312c6397fe69e75cc8a97295b9c11ea7a8292a12b8d5

If link doesn't work:

go to: https://www.cnj.jus.br/pjecnj/ConsultaPublica/listView.seam

Search for 0007539-46.2020.2.00.0000, open de result and try to take a full page screenshot.

I'd like to add a personal opinion that working full page screenshots are the only reason Firefox should even have such native capability in the first place, considering OSes already provide native screenshot tools to whatever is visible...

Comment 10

[Leslie]

(In reply to Sam Foster [:sfoster] (he/him) from comment #4)

I'm adjusting the bug title here as we see this on a lot of sites which set body/html overflow:hidden and use a child element as the primary scrollable content area.

Hi Sam, my name is Leslie and I am an Outreachy applicant. Is this a good bug to work on for the Screenshots Project? Can I be assigned to it?

Comment 11

[Emma Malysz]

Hi Leslie, I would recommend starting with a bug from this list! https://bugzilla.mozilla.org/buglist.cgi?emailassigned_to1=1&keywords_type=allwords&query_format=advanced&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&email1=nobody%40mozilla.org&query_based_on=Good%20First%20Bugs&emailtype1=substring&resolution=---&keywords=good-first-bug&order=changeddate%20desc&list_id=15674509

Comment 12

[Sam Foster [:sfoster] (he/him)]

There are lots of pages with overflow:hidden on the document element, a sticky header or footer, and a content area that has overflow:auto. See the dupes for examples. searchfox.org is also one. The user can choose from Screenshots UI if they want the visible page, or the full page. When we screenshot the tab, the document element has overflow:hidden so there's nothing to scroll and the resulting screenshot is really just the visible page. I'm not sure if we have an existing or clever way to do this. But at first glance it looks like we would need to walk down the DOM looking for elements with overflow, pick the largest one and capture that. Or look at the document.activeElement and walk up from there to find the closest scrollable container?

I feel like this must be a solved problem in the codebase already. How do we know what element to scroll when we get scroll wheel events? :emilio, do you have thoughts, can you direct this to someone who would know?

Currently Screenshots is a web extension and uses browser.tabs.captureTab for the actual screenshot-ing. We are starting the process of migrating it to a regular browser component so we aren't constrained to web extension APIs for a solution.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

This is not quite a solved problem, because it's not quite trivial to know that a non-root scrollable element should be "expanded", and if so, how... Consider the case of two vertically-adjacent scrollable regions... Should the top one be expanded? And if so, should it push the bottom one?

This is fixable, but not trivially, afaict... Requires more investigation to find the cases that we do want to support, and currently I'm not sure if captureTab does layout (I suspect not), but expanding scrollable elements would cause us to have to run some sort of magic layout pass that expands scrollable elements and pushes stuff down (which is not an issue with the root scroller).

Comment 14

[jscher2000]

Not sure whether this is the same issue or a variation: the Chrome web store overlays extension details in fixed-position divs which are only captured to the extent they fit in the current viewport. For example:

https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:sfoster, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[Sam Foster [:sfoster] (he/him)]

(In reply to jscher2000 from comment #14)

Not sure whether this is the same issue or a variation: the Chrome web store overlays extension details in fixed-position divs which are only captured to the extent they fit in the current viewport. For example:

https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en

Yeah I think that is likely another instance of this same issue.

The case :emilio describes in comment 13 where you have e.g. 2 side by side scrollable elements and its not clear whether to pick one or both to scroll or how that would even work is probably out of scope for this bug. But there is a common case where a single scrollable element occupies 100% of the viewport's width and height where a simple heuristic might help us produce the screenshot people expect.

Comment 18

[Alexander]

Can we request a full screenshot of a single scrollable area? That would be a super useful first step.

Comment 19

[B.J. Herbison]

(In reply to Alexander from comment #18)

Can we request a full screenshot of a single scrollable area? That would be a super useful first step.

Do the images attached to bug 1696637 show what you want?

Comment 20

[Teal Dulcet [:tdulcet] (TB Council)]

(In reply to Sam Foster [:sfoster] (he/him) from comment #16)

The case :emilio describes in comment 13 where you have e.g. 2 side by side scrollable elements and its not clear whether to pick one or both to scroll

There are several add-ons including GoFullPage and FireShot that allegedly solve this by scrolling each scrollable area independently and then automatically combining the resulting screenshots, but they are either not available on AMO or require a paid subscription, so it would be great if this functionality could be included with the Firefox screenshot tool.

Comment 25

[travneff]

I see something similar at web.telegram.org channel comment threads.

Needs Telegram account:

• select any channel with comments enabled (for example: @uniannet)
• enter its comments thread with Firefox at web.telegram.org
• scroll some comments by keyboard (PageUp/PageDown)
• make "Save full page" screenshot

Expected result: contains some scrolled parts (more than visible).
Actual result: no scrolled parts, only visible area saved.

Comment 26

[travneff]

For Twitter comments, Firefox recognizes their long space correctly but only first of them are rendered on screenshot. Rest of the scrollable area is shown empty.