[webkit-reviews] review requested: [Bug 38424] add support for text/html-sandboxed on sandboxed iframes : [Attachment 64691] Proposed patch

[bugzilla-daemon at webkit.org]

Patrik Persson <patrik.j.persson at ericsson.com> has asked  for review:
Bug 38424: add support for text/html-sandboxed on sandboxed iframes
https://bugs.webkit.org/show_bug.cgi?id=38424

Attachment 64691: Proposed patch
https://bugs.webkit.org/attachment.cgi?id=64691&action=review

------- Additional Comments from Patrik Persson <patrik.j.persson at ericsson.com>
This implementation is based on the current WhatWG specifications:

 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.
html
 
http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html#text/html
-sandboxed

Content of type 'text/html-sandboxed' is rendered only if the loading
frame is sandboxed wrt. origin.  (Without the patch, Safari renders
'text/html-sandboxed' like 'text/plain,' while Chrome offers to save
the file instead.)

We've made a few assumptions in this patch, and we invite you to
challenge them:

* We interpret the spec to imply that the sandbox attribute must be
  explicitly assigned to the iframe element, rather than implicitly
  inferred from the Content-type response header of the document in
  the iframe.

* We interpret the spec to imply that the loading iframe only needs to
  have the 'SandboxOrigin' flag set.  This means that a
  'text/html-sandboxed' document can still run scripts, submit forms,
  and so on.

* We suspect that browsers may want to provide more detailed feedback
  to the user when 'text/html-sandboxed' content is suppressed
  (perhaps by adding callbacks in FrameLoaderClient).  However, we
  have currently not anticipated the design decisions for such
  feedback, since we assume browser vendors know this area better.