New issue
Advanced search Search tips

Issue 746564 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Sep 13
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Error information obscured for exceptions from `eval` in source-less iframes

Reported by m...@bocoup.com, Jul 19 2017

Issue description

Chrome Version: 59.0.3071.109 (Developer Build)
OS Version: GNU/Linux, Ubuntu 16.04 (64 bit)
Other browsers tested: Firefox 54.0 (this is not a problem in that browser)

What steps will reproduce the problem?

1. Create a web page that performs the following:
  1. Create an iframe
  2. Define a global `onerror` handler within the iframe
  2. Insert a script in the iframe which contains a call to `eval` that
     produces an error
2. Finally, access that web page from a server (i.e. *not* via the `file://`
   protocol).

What is the expected result?

The actual object and stack trace should be reported.

What happens instead of that?

Note that the `onerror` handler is invoked with the generic "script error" name
and without the error object or stack trace

Please provide any additional information below. Attach a screenshot if
possible.

This is limited to iframes that have no `src` attribute. If the document is
written to prior to script injection, then the resultant `onerror` invocation
contains the expected error information.

Example document:

    <!DOCTYPE html>
    <html>
    <body>
    <script>
    var iframe = document.createElement('iframe');
    document.body.append(iframe);
    var iwin = iframe.contentWindow;

    // Un-commenting the following statement will cause Chromium to provide the
    // complete error information in the subsequent invovation of `onerror`:
    //iwin.document.write('<body>');

    var script = document.createElement('script');
    script.innerText = 'eval("#")';
    iwin.onerror = function() {
        Array.from(arguments).forEach((el, idx) => console.log(idx, el));
      };

    iwin.document.body.appendChild(script);
    </script>
    </body>
    </html>

Thanks for your consideration, and thanks for the terrific browser!
 
Labels: Needs-Milestone
Cc: kkaluri@chromium.org
Components: UI
Labels: M-62 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Windows 10, Ubuntu 14.04 & Mac 10.12.5 with chrome Stable #60.0.3112.78 canary #62.0.3167.0 and also in earlier version M54-54.0.2840.98, this is a non-regression issue, hence marking it as untriaged.

These are the steps followed:
1. Created a html file with the provided code in comment #0
2. Started the python web server.
3. loaded the test html page

Observations:
1. In M54 & later builds, on loading test html page observed script error in the console
2. In below M54 builds, on loading test html page observed "TypeError: document.body.append is not a function"

Attaching the screenshot for reference.

Note: Issue is not reproducible in FireFox.

Thank You...
746564-M54.png
97.3 KB View Download
746564-M53.png
89.2 KB View Download
746564-FF.png
100 KB View Download

Comment 3 by joe...@ripjar.com, Nov 2 2017

This issue also occurs without any iframe.

Tested in M62.0.3202.75 and Canary 64.0.3256.0, both 64 bit on macOS Sierra 10.12.6 (16G29).

Steps to reproduce:

1. Create a web page containing this markup:

<!doctype html>
<body>
<script>

window.addEventListener("error", (err) => {
  console.log("error event:", err.message);
})

// sync and async errors are both affected 
eval(`setTimeout(() => { throw new Error("async error") }, 100)`)
eval(`throw new Error("sync error")`);

</script>
</body>


2. Access this page over HTTP

Expected and actual results as the original ticket. Firefox doesn't obscure the error.
Status: Archived (was: Untriaged)
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Sign in to add a comment