New issue
Advanced search Search tips

Issue 600849 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Moving HTMLMediaElement to new document should not invoke load algorithm or otherwise reset state

Project Member Reported by wolenetz@chromium.org, Apr 5 2016

Issue description

While rebaselining layout expectations to include media error messages reported to devtools console (https://codereview.chromium.org/1858073002/), I found that media/media-reparent.html was:
1) Flakily *not* reporting the devtools error message if the test is run in isolation. (I suspect this is due to low timeout in endTestLater(), not this bug.), and
2) Unable to end the test without timing out, using "waitForEventAndEnd('error');" instead of "endTestLater();"

Inspection with logging enabled showed:
ERR: HTMLMediaElement::insertedInto(0x29a6c5d24f80, 0x29a6c5d24f28)\n
ERR: HTMLMediaElement::removedFrom(0x29a6c5d24f80, 0x29a6c5d24f28)\n
ERR: HTMLMediaElement::insertedInto(0x29a6c5d24f80, 0x29a6c5d24ec0)\n
ERR: HTMLMediaElement::stop(0x29a6c5d24f80)\n
...
ERR: HTMLMediaElement::setNetworkState(0x29a6c5d24f80, 4) - current state is 2\n
ERR: HTMLMediaElement::noneSupported(0x29a6c5d24f80)\n

((next line From https://codereview.chromium.org/1858073002/#ps1))
ERR: HTMLMediaElement::reportPlayerErrorToDevToolsConsole(0x29a6c5d24f80)\n

((the lines book-ending the error scheduling are added while initially investigating this issue, demonstrating that m_asyncEventQueue is closed still:))
ERR: HTMLMediaElement::nonesupported(0x29a6c5d24f80) before scheduling error event, does the async queue have any pending events? 0\n
ERR: HTMLMediaElement::scheduleEvent(0x29a6c5d24f80) - scheduling 'error'\n
ERR: HTMLMediaElement::nonesupported(0x29a6c5d24f80) after scheduling error event, does the async queue have any pending events? 0\n

ERR: HTMLMediaElement::setShouldDelayLoadEvent(0x29a6c5d24f80, false)\n
ERR: HTMLMediaElement::pause(0x29a6c5d24f80)\n
ERR: HTMLMediaElement::pauseInternal(0x29a6c5d24f80)\n
ERR: HTMLMediaElement::updatePlayState(0x29a6c5d24f80) - shouldBePlaying = false, isPlaying = false\n
 IN: ^D
[1/1] media/media-reparent.html failed unexpectedly (test timed out)


philipj@: This doesn't seem like the correct behavior. When a media element is reparented, what should happen to any events enqueued prior to removedFrom, and any enqueued after a later insertedInto?
 

Comment 1 by phil...@opera.com, Apr 6 2016

Cc: sriram...@samsung.com
Summary: Moving HTMLMediaElement to new document should not invoke load algorithm or otherwise reset state (was: HTMLMediaElement reparenting needs to be able to deliver events to new parent)
This test moves the media element between documents, which isn't supported per spec. In HTMLMediaElement::didMoveToNewDocument there's a call to invokeLoadAlgorithm(), and a FIXME that explains why it's there. This is not per spec at all, of course.

Invoking the load algorithm removes all pending events, so I think that this test should reliably have no error event fired, is that what you're seeing? As for the flaky error message, I suspect that the reportPlayerErrorToDevToolsConsole is for the load that's triggered by moving to a new document, can you confirm? If so, what happens to the error event that's scheduled just after that? The media element doesn't move again, so if it's never fired I don't know what's going on.
Labels: Needs-BlinkMediaTriage

Comment 3 by foolip@chromium.org, Nov 11 2016

Cc: foolip@chromium.org
Owner: ----
Status: Available (was: Assigned)
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 13 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)
Project Member

Comment 6 by sheriffbot@chromium.org, Dec 3

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Sign in to add a comment