Unable to reproduce this issue on Ubuntu 14.04 with chrome dev #58.0.3013.3

These are the steps followed

1. Launched chrome and navigate to "Youtube.com"
2. In the browser console pasted the following code 
    (function() {
    var element = document.createElement('audio');
    element.onerror = function() {
      window.location = window.location;
    };
    element.src = '.?' + new Date().getTime();
    }());

3. Observed that youtube page got immediately refreshed.

Attaching the screen-cast for reference.

mike@ could you please look into it and let us know any steps i have missed while reproducing the scenario.

Thank You...

Deleted: Issue 695096.mp4 2.2 MB

	Issue 695096.mp4 2.2 MB View Download

Thanks for taking a look. An important detail missing from your attempt to
reproduce this bug is the creation of a dedicated document. By executing the
provided script in the developer console, it will only be run one time. The
erroneous behavior is exhibited irregularly. This is the significance of the
statistics I shared: only 2.5% of trials failed on my system. This means the
bug may not be appreciable in a single trial.

My original report recommended a dedicated document so that the trial would be
run many times automatically and so that a failure would halt execution of
further trials.

Thank you for providing feedback. removing "Needs-Feedback" label.

Any chance you can provide a test page that we could use to reproduce the issue?

Sure, see attached. Note that this file simply contains the text from my
initial report. Note also that it must be loaded via a web server--accessing it
via the `file://` protocol does not seem to trigger the bug.

Deleted: media-element.html 216 bytes

media-element.html 216 bytes View Download

I put this page in https://mounirlamouri.github.io/sandbox/bugs/695096.html and I can't reproduce on 59.0.3043.0

Can you try with a similar set up?

The script I shared in my issue report made an invalid
assumption: that the server would respond to requests for the document's
directory (i.e. .) with an HTTP 2xx status code. The webserver I have been
using for local testing behaves in this way (providing a directory listing),
but the server implemented by GitHub on github.io does not.

I'm attaching a corrected version that corrects this. (I've also submitted a
patch to your git repository in case that is easier.)

Deleted: 695096.html 238 bytes

695096.html 238 bytes View Download

That's also available on my fork of your repository:

https://jugglinmike.github.io/sandbox/bugs/695096.html

I've attached a recording of the reported behavior as I am experiencing it.

Deleted: 695096.gif 842 KB

	695096.gif 842 KB View Download

Thank you for providing more feedback. Adding requester "mlamouri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm, I can't reproduce with 59.0.3063.4 on Linux with the URL in Comment 12.

Mike, I can't reproduce this on a M59 build too. Can you still reproduce this issue?

Yes, I am still experiencing this bug on version 59.0.3067.0. It continues to
be rare, though, sometimes requiring over 500 trials before being expressed. I
spent some time tonight trying to nail down conditions to reproduce the
behavior more consistently, but I haven't had any luck. For instance, forcing
garbage collection by calling `gc()` (as exposed via
`--js-flags="--expose-gc"`) does not seem to help.

In what I hope is the next best thing, I am additional debugging data (enabled
using `--enable-logging=stderr --v=1`). This documents some of the internal
state for an error-free trial and for a failing trial that immediately followed
it. Note that in the successful trial, two "contexts" are created, reported as
"tracked," and subsequently destroyed. In the failing trial, no "contexts" are
created, although the "Destroyed context for extension" message is nonetheless
emitted.

I'm not sure if the "extension" referenced in these logs refers to the same
concept as the term "extension" as used in the UI. To be safe, I have uninstalled
all such extensions, but I am still seeing the same logging output.

Because the network connection to GitHub.com introduces a source of variability
that does not appear to be necessary, I have also attached Python source code
for an HTTP server that can be used to demonstrate this behavior. In
environments that have Python 2.7 available, the script can be executed via the
following command:

    python media-element.py

That makes a demonstration web page available at http://localhost:8009

Deleted: 17.04.20.chromium.log 2.2 KB

17.04.20.chromium.log 2.2 KB View Download

Deleted: media-element.py 724 bytes

media-element.py 724 bytes View Download

Thank you for providing more feedback. Adding requester "mlamouri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mike, I ran your script for 5 mins and things were working fine. Do you have this running in the background by any chance? I believe this is throttled when running in the background.

The browser has been the foreground process during my local testing. (Although note that even in the presence of request throttling, the reported behavior would still be a bug.) When it comes to reproducing the problem, I'm using the same procedure in the recording from comment 12.

Thank you for providing more feedback. Adding requester "mlamouri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm I could not reproduce this on M60. Mike can you reproduce on M60?

I sure can :) I've attached a new screen recording, this time running from
Chrome version "60.0.3112.20 (Official Build) dev (64-bit)". The platform is
the same as in my prior reports: version 16.04 of Ubuntu GNU/Linux.

Note that the Developer Tools pane is open in these screen recordings solely
for demonstration purposes. I experience the unexpected behavior whether that
pane is open or not. Note that to be safe (and unlike in the previous
recording), I have un-checked the UI checkbox labeled "Disable cache". Again,
this detail does not effect my ability to reproduce the bug.

Deleted: m60.gif 813 KB

	m60.gif 813 KB View Download

Thank you for providing more feedback. Adding requester "beccahughes@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks :) I tried it on M58, M59 and M60 across OSX / Ubuntu but unfortunately I can't seem to reproduce it.

Do you have any more information, or anything that can help us reproduce the issue? If not, i'm afraid we will have to mark this as WontFix because we can't fix it if we can't reproduce it.

I'm really sorry about that but as beccahughes@ said, we have to close this because we can't reproduce the issue. If we find a way to reproduce the  issue 100 % or have more information please ping the bug. We would be happy to have another look.

The NextAction date has arrived: 2017-06-21