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

Issue 759214 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

'securitypolicyviolation' DOM event is raised in a wrong frame by 'plugin-types' CSP

Project Member Reported by lukasza@chromium.org, Aug 25 2017

Issue description

REPRO:

1. Modify http/tests/security/contentSecurityPolicy/1.1/plugintypes-affects-cross-site-child-disallowed.html layout test to also listen for the 'securitypolicyviolation' DOM event.  Example:

     <!DOCTYPE html>
     <html>
     <head>
    +  <script src="/resources/testharness.js"></script>
    +  <script src="/resources/testharnessreport.js"></script>
       <meta http-equiv="Content-Security-Policy" content="plugin-types text/plain">
       <script src="../resources/dump-as-text.js"></script>
    +  <script>
    +      async_test(t => {
    +          var watcher = new EventWatcher(t, document, ['securitypolicyviolation']);
    +          watcher
    +              .wait_for('securitypolicyviolation')
    +              .then(t.step_func(e => {
    +                  assert_equals(e.blockedURI, "TODO/FIXME");
    +                  assert_equals(e.lineNumber, 7, "TODO/FIXME");
    +                  t.done();
    +              }));
    +
    +          window.onmessage = t.unreached_func('No message should be sent from the frame.');
    +      }, "The plugin type is blocked.");
    +  </script>
     </head>

2. Run the test - observe an unexpected timeout (both with and without --site-per-process).

3. Perform an ad-hoc / temporary modification of ContentSecurityPolicy::DispatchViolationEvents
   to dispatch the event to the *parent* of |execution_context_|:

      ExecutionContext* ec = ToLocalFrame(
           execution_context_->ExecutingWindow()->GetFrame()->Tree().Parent()
      )->GetDocument();

4. Run the test again - observe no timeout (confirming [I think] the hypothesis that the event is dispatched to the wrong frame).


EXPECTED BEHAVIOR: No timeout in step 2

NOTE: Even though I've used testharness.js in step1 above, I am not sure if this is a viable long-term approach for the layout test in question (because I don't know how to verify absence of "Blink Test Plugin: initializing" console message without comparing with -expected.txt)
 
Description: Show this description
Owner: andypaicu@chromium.org
Status: Assigned (was: Untriaged)

Comment 3 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 4 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment