screenshot command in Web Developer toolbar is broken in Tor Browser

When I try use the command it returns "unknownError"

Linux Tor Browser 7.0.9 (based on Mozilla Firefox 52.4.1) (64-bit)

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::reopened tbb-usability type::defect labels

Do you have steps to reproduce that?

Trac:
Owner: N/A to tbb-team
Keywords: N/A deleted, tbb-usability added
Component: - Select a component to Applications/Tor Browser
Status: new to needs_information

Just open Tor Browser and go to any site ,say, Wikipedia. In the Developer Toolbar (Shift+F2) at the bottom type in screenshot image_name hit enter

Normally a screen shot is taken but now its simply says "unknownError"

As I was writing the previous comment I checked it and the issue occured. After I was finished I decided to try on Wikipedia ... just to be sure. This time I got a different error: "TypeError: this.target.tab is null"

Haven't seen that before.

As I am writing this I switched back to the Wikipedia tab for one more test and I got the usual error this time: ""unknownError"

And there's more... if I open an empty tab it takes a screen shot! A plain white screen shot. Going back to the other tabs with content and the error returns.

Trac:
Status: needs_information to new

Trac:
Resolution: N/A to worksforme
Cc: N/A to cypherpunks
Status: new to closed

Hi original poster here. What does "closed defect (worksforme)" mean: this is a one off anomaly and only impacts my copy of TorBrowser? Thanks.

Trac:
Status: closed to reopened
Resolution: worksforme to N/A

That's due to #22692 (moved). I get the following in my terminal:

Message: Unix error 13 during operation stat on file image_name

Setting security.sandbox.content.level to anything less than 2 it "works". I wonder if #23970 (moved) would fix this issue as well.

Trac:
Cc: cypherpunks to pospeselr

Replying to gk:

That's due to #22692 (moved). I get the following in my terminal: {{{ Message: Unix error 13 during operation stat on file image_name }}} Setting security.sandbox.content.level to anything less than 2 it "works". I wonder if #23970 (moved) would fix this issue as well.

It does not (which isn't terribly surprising). The patches in #23970 (moved) are specifically about serializing over the relevant font information from the sandboxed Web Content process to foreground firefox process so that the print.print_via_parent option works correctly. Prior to the changes there, the print_via_parent option 'worked' but no fonts would be in the final rendered pdf/ps file.

The issue here is almost certainly a file permissions issue since if you explicitly set a path the sandbox process has access to with the screenshot command (ie screenshot /tmp/screenshot.png the operation succeeds. The generated screenshot file and path will need to be broker'd over to the foreground which has access to the user's file system.

The reason why some pages (empty tab, about:support, etc) can be screenshot (or successfully print-to-file'd prior to the #23970 (moved) fix) is (presumably) because they are hosted in the firefox process, rather than the sandboxed Web Content process, which seems kind of off. For instance, if the strings in the about:support page are not properly sanitized, I could imagine sandbox-escape where a malevolent extension exercising some exploit through a malicious string in the Name, Version or ID strings.

Replying to pospeselr:

Replying to gk:

That's due to #22692 (moved). I get the following in my terminal: {{{ Message: Unix error 13 during operation stat on file image_name }}} Setting security.sandbox.content.level to anything less than 2 it "works". I wonder if #23970 (moved) would fix this issue as well.

It does not (which isn't terribly surprising). The patches in #23970 (moved) are specifically about serializing over the relevant font information from the sandboxed Web Content process to foreground firefox process so that the print.print_via_parent option works correctly. Prior to the changes there, the print_via_parent option 'worked' but no fonts would be in the final rendered pdf/ps file.

The issue here is almost certainly a file permissions issue since if you explicitly set a path the sandbox process has access to with the screenshot command (ie screenshot /tmp/screenshot.png the operation succeeds. The generated screenshot file and path will need to be broker'd over to the foreground which has access to the user's file system.

The reason why some pages (empty tab, about:support, etc) can be screenshot (or successfully print-to-file'd prior to the #23970 (moved) fix) is (presumably) because they are hosted in the firefox process, rather than the sandboxed Web Content process, which seems kind of off. For instance, if the strings in the about:support page are not properly sanitized, I could imagine sandbox-escape where a malevolent extension exercising some exploit through a malicious string in the Name, Version or ID strings.

Makes sense, thanks. So, the question boils down to why just specifying a filename without an absolute path is working in vanilla Firefox but not Tor Browser then I guess.

moved to tpo/applications/tor-browser#24177 (closed)