New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 1
Type: Feature

Blocked on:
issue 744499

Sign in to add a comment

Issue 636981: Cannot add FTP exception to SiteSettings

Reported by, Aug 11 2016 Project Member

Issue description

Version: Version 54.0.2826.0 canary (64-bit)
OS: Windows 7

What steps will reproduce the problem?
(1) Visit chrome://settings/siteSettings/javascript
(2) Attempt to add a "Block" exception for or ftp://*
(3) Cannot save the exception; save button never enabled

Comment 1 by, Sep 28 2016

FTP patterns are apparently not even supported by the ContentSettingsPattern class:

I'd therefore argue UI>Settings is the wrong component for this bug -- or, at least you'd need changes elsewhere before this can be taken further.

Comment 2 by, Oct 27

Components: -UI>Settings Internals>Permissions>Model
Labels: -Type-Bug Type-Feature

Comment 3 by, Nov 12

Labels: OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac
Status: Assigned (was: Untriaged)
Adding msramek as an OWNER for ContentSettingsPattern. msramek: Can you help further triage/reassign? Thanks. (Also added all platforms, since this is not Windows specific).

Comment 4 by, Nov 12

Labels: -Pri-2 Pri-1
ftp:// is not listed in kSchemeNames[] in ContentSettingsPattern.

As a result, it seems that content settings don't apply to it. Not just exceptions, but also the default setting. I just tested disabling JavaScript completely, and was still able to execute console commands on

Ideally, we would keep kSchemeNames[] in sync with the "webby" schemes defined in url/. Alternatively, we could decide that HTML served on ftp:// can't have some functionality, including running JavaScript, at all, but that would be a more far-reaching decision.

Passing to engedy@ and increasing priority, as I think this is a big oversight.

Comment 5 by, Nov 15


Since we're now deprecating rendering FTP resources, and the only documents we'd render on ftp:// now are directory listings, and we know that those won't contain JavaScript, it should now be safe to just blanket-disable JS on ftp://, right?

Comment 6 by, Nov 16

msramek@: Yes, if we get approval to fix  issue 744499  in!topic/blink-dev/eopgOoY1QLs, then we could simply block all features on `ftp://` pages without issue.

Comment 7 by, Nov 16

Blockedon: 744499

Sign in to add a comment