Opened 2 years ago

Closed 23 months ago

Last modified 11 months ago

#23397 closed defect (wontfix)

NoScript blocks PDFs in frames unless their ancestors are Javascript-allowed

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security-slider, noscript
Cc: gk, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Steps to reproduce the issue:

  1. Open Stock Tor Browser 7.5a4.
  2. Set the security setting to Low.
  3. Visit https://web.archive.org/save/https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf, after some time PDF should show up.
  4. Set the security setting to Medium.
  5. Refresh the page.
  6. PDF wont show up no matter how much you wait :(

There's nothing in the stuff that is disabled at Medium security setting that would cause the PDF to not show up, so this is most definitely a bug.

Child Tickets

Change History (11)

comment:1 Changed 2 years ago by gk

Keywords: tbb-security-slider added
Severity: MajorNormal

comment:2 Changed 2 years ago by cypherpunks

Keywords: noscript added
15:29:06.073 TypeError: keys[0].match(...) is null 1 Main.js:1266:20

instead of reloading this page with JS temporarily enabled at High.

comment:3 Changed 2 years ago by cypherpunks

Workaround: "Temporarily allow all this page" and refresh (F5).

comment:4 in reply to:  3 ; Changed 2 years ago by cypherpunks

Replying to cypherpunks:

Workaround: "Temporarily allow all this page" and refresh (F5).

Only for High security setting.

Also I tested it with stable Tor Browser and same problem, so it doesn't have to do with the recent Torbutton fix.

Also better title is welcome :)

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:5 in reply to:  4 Changed 2 years ago by cypherpunks

Summary: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security SettingNoScript is totally brain damaged with the way it handles URLs (with e.g. https:// inside)

Replying to cypherpunks:

Replying to cypherpunks:

Workaround: "Temporarily allow all this page" and refresh (F5).

Only for High security setting.

Not only ;)

Also I tested it with stable Tor Browser and same problem, so it doesn't have to do with the recent Torbutton fix.

Also better title is welcome :)

How about this?

comment:6 Changed 2 years ago by teor

Summary: NoScript is totally brain damaged with the way it handles URLs (with e.g. https:// inside)NoScript is totally broken in the way it handles URLs (with e.g. https:// inside)

Or this

comment:7 Changed 2 years ago by cypherpunks

To the other cypherpunk, are you sure that this is a NoScript bug? I don't have time to test but does this happen with a stock Firefox 52-esr with NoScript?

comment:8 Changed 2 years ago by cypherpunks

comment:9 Changed 23 months ago by ma1

Resolution: wontfix
Status: newclosed
Summary: NoScript is totally broken in the way it handles URLs (with e.g. https:// inside)NoScript blocks PDFs in frames unless their ancestors are Javascript-allowed

The console error in #comment:2 about URL parsing is completely unrelated (about port number shortcuts) and fixed in recent NoScript versions.
The new title says it all: JavaScript blocking is cascaded to child frames, and since PDF.js quite obviously relies on JavaScript to render PDFs, it won't work in a frame unless its ancestors are allowed. Wontfix.

comment:10 Changed 23 months ago by cypherpunks

Good news anyway: pdfjs will hopefully get replaced by Chromium's PDFium by the next ESR, see last comments in #7501.

Last edited 23 months ago by cypherpunks (previous) (diff)

comment:11 Changed 11 months ago by cypherpunks3

This problem doesn't happen with NoScript WebExtension, not sure if that's intentional.

Note: See TracTickets for help on using tickets.