Closed Bug 1210031 Opened 9 years ago Closed 9 years ago

Node screenshot is cut off on large elements

Categories

(DevTools :: Inspector, defect)

Product:
DevTools
Component:
Inspector
Version:
41 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox45 fixed)

Status:
RESOLVED FIXED
Milestone:
Firefox 45
Tracking Flags:
Tracking Status
firefox45 --- fixed

People

(Reporter: brunoveilleux, Assigned: jryans)

References

Details

(Whiteboard: [polish-backlog])

Attachments

(4 files)

info1.html
4.79 KB, text/html
Details
node_selection.png
153.71 KB, image/png
Details
node_screenshot.png
19.44 KB, image/png
Details
MozReview Request: Bug 1210031 - Only subtract scrollbars for window screenshots. r=zer0
40 bytes, text/x-review-board-request
zer0
: review+
Details
Attached file info1.html — 
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150918100310

Steps to reproduce:

Launch Firefox.
Open a Web page that contains an element with a specific width and an automatic length of at least 700 pixels (sample file attached).
Open the developer tools (right-click > Inspect Element (Q)).
Right-click the <body> element > Screenshot Node.
Save file locally.


Actual results:

Instead of the specified width (in the sample, 1000 pixels), the image has a width 13 pixels smaller (987 with the sample). No matter what width is used, the resulting screenshot's width is 13 pixels smaller (resulting in broken images if the specified width is under 14 pixels). However, if the element's height goes under approximately 700 pixels (by removing some of the text), the screenshot has correct dimensions.


Expected results:

The entire element should be captured regardless of its size.
Component: Untriaged → Developer Tools
OS: Unspecified → Linux
Product: Core → Firefox
Hardware: Unspecified → x86_64
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151009030230

I can confirm this behavior on my system.

I also noticed it with nodes of lower heights like the performance comparison table on http://julialang.org/ (see attached screenshots).
Attached image node_selection.png — 

    
    

    
  

      
      
      
      

        Attached image
          
        node_screenshot.png
        — 
      

    


  

    
    

    
  
FWIW, for me at OS-level zoom of 200% (Windows 7 HP), clipped area is approx 35px wide.

    
    

    
  
…and approx 14px wide with the reporter's attachment 8667974 [details].

    
    

    
  
In further testing, I think I've gotten to the core of the issue.

The 700px size in comment 0 is not really critical.  What is important is that the window is short enough vertically that a vertical scrollbar appears in the window.  The width that is cut off is roughly the width of the vertical scrollbar.

Mac uses floating scrollbars by default, but you can also trigger it there by setting Show scroll bars -> Always.
Assignee: nobody → jryans
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Whiteboard: [polish-backlog]
Component: Developer Tools → Developer Tools: Inspector

    
    

    
  
Comment on attachment 8685766 [details]
MozReview Request: Bug 1210031 - Only subtract scrollbars for window screenshots. r=zer0

Looks good to me. Should we add some tests about this? To ensure that the image's size are correct both for element and window screenshot?

        Attachment #8685766 -
        Flags: review?(zer0) → review+

    
    

    
  
Well, reading from the clipboard was quite an uphill battle... but anyway, I've added some tests!

https://treeherder.mozilla.org/#/jobs?repo=try&revision=296553919fe7

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/9a90fc88892f
Status: ASSIGNED → RESOLVED
Closed: 9 years ago

          status-firefox45:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45

    
  
Product: Firefox → DevTools

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: