NoScript interferes with Reader View mode

RESOLVED INVALID

Status

()

Toolkit
Reader Mode
RESOLVED INVALID
2 years ago
8 months ago

People

(Reporter: petruta, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox40 affected)

Details

(Reporter)

Description

2 years ago
Reproducible on:
 Firefox 38 beta 6
 latest Aurora 39.0a2 2015-04-23
 latest Nightly 40.0a1 2015-04-13 NON e10s window
Not reproducible on:
 latest Nightly 40.0a1 2015-04-13 e10s window

Steps to reproduce:
1. Install NoScript add-on and restart the browser
2. Open an article (eg from http://www.foxnews.com/ )
3. Click the Reader View icon on the location bar

Actual results:
The article is blocked by NoScript, only "-" icon is shown on the page. The tab title is: about:reader?url=http...

Expected results:
Tab title should not appear as "about:reader". I believe NoScript should not interfere with an integrated Firefox feature such as Reader View.

Notes: 1. Issue reproduces under Win 7 64-bit, Ubuntu 13.04 64-bit and Mac OS X 10.9.5.
2. "Allow about:reader" NoScript option can be selected to display the article in reading view format.

Updated

11 months ago
Duplicate of this bug: 1166455

Comment 2

11 months ago
If NoScript is deliberately doing this, I don't think it's useful for Firefox to do much to try to counteract this, so going to resolve this bug.

That said, I'm not sure why NoScript is doing this. We already use sanitization on about:reader and so no content-originated JS should ever be running on it. While there's more defense in depth that could happen (e.g. bug 1204818), I wonder if Giorgio would consider enabling the about:reader option by default and/or contributing to whatever he thinks should happen to make this work out of the box.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Flags: needinfo?(g.maone)
Resolution: --- → INVALID

Comment 3

8 months ago
Sorry for the late answer.
The reasons why about:reader is not whitelisted is that markup sanitization is not perfect and researchers out there can always figure out a new way to work-around it, e.g. by leveraging new elements, attributes or event handler added by the ever changing HTML5 spec.

Bug 1204818 (a sandboxed iframe) is definitely a step in the right direction: I suppose it's meant to be the "web-centric" equivalent of the old, proven way, i.e. disabling scripts in content and wiring the UI from chrome-side event handlers.
Flags: needinfo?(g.maone)
You need to log in before you can comment on or make changes to this bug.