1055579 - Error event called in Windows 7, while not on other platforms

Status: REOPENED

(Core :: Audio/Video: Playback, defect)

Description

[Martijn Wargers (dead)]

This is a follow-up from bug 1024535. See bug 1024535, comment 54 and further.

Basic summary:
test_load_candidates.html was firing error events when the test file would unload (which the patch for bug 1024535 fixes).
On other platforms this doesn't happen.

I don't know what the intended behavior is, but it should at least be consistent across all platforms.

I'll try to come up with a mochitest, shortly.

Comment 1

[Martijn Wargers (dead)]

Attachment: 1055579_mochitest.diff

Mochitest for this bug.
I haven't test this yet on Windows 7, will do shortly.

Comment 2

[Martijn Wargers (dead)]

Unfortunately, the mochitest also passes on Windows 7, so I'll have to add stuff from test_load_candidates.html to see where the generated error is coming from.

Comment 3

[Martijn Wargers (dead)]

Attachment: 1055579_mochitest.diff

Hmm, this doesn't even show the error in Windows 7, which is almost like the situation in test_load_candidates.html minus the patch from bug 1024535.
I guess I should just try to minimize with the situation from test_load_candidates.html minus the patch from bug 1024535, but with the final patch from bug 1032878.
This can take a while, because I would then have to run the whole content/media/test/ directory to see the error and running mochitests on Windows 7 already seems slower.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Do you see any assertions/warnings in the logs? Sometimes we hit this path on Windows:
http://mxr.mozilla.org/mozilla-central/source/content/media/wmf/WMFReader.cpp#526

When we return failure here, it causes an "error" event to be dispatched to JS.

We can hit this failure on Windows as there's some limit to the number of decoders it can run at once. We hope that will be fixed once we switch from using the WMFReader to the MP4Reader on Windows.

Or maybe you're seeing something else?

Comment 5

[Martijn Wargers (dead)]

Unfortunately, I wasn't able to build a debug build on my Windows 7 VM, only opt, something with the xul.dll size or something, iirc.
I'll just recreate test_load_candidates.html and start from there (tomorrow, though).

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Chris Pearce (:cpearce) from comment #4)
> Do you see any assertions/warnings in the logs? Sometimes we hit this path
> on Windows:
> http://mxr.mozilla.org/mozilla-central/source/content/media/wmf/WMFReader.
> cpp#526
> 
> When we return failure here, it causes an "error" event to be dispatched to
> JS.
> 
> We can hit this failure on Windows as there's some limit to the number of
> decoders it can run at once. We hope that will be fixed once we switch from
> using the WMFReader to the MP4Reader on Windows.

If that is the case, we can try to call removeNodeAndSource() at [1] instead to ensure decoders are released after finishing each file.

[1] http://hg.mozilla.org/mozilla-central/file/149d3ce6e020/content/media/test/test_load_candidates.html#l32

Hi Martijn,
Can you give it a try by changing |v.parentNode.removeChild(v)| to |removeNodeAndSource(v)| and reverting the change in bug 1024535 to see if that solve the mysterious error event on Windows.

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

(In reply to JW Wang [:jwwang] from comment #6)
> Hi Martijn,
> Can you give it a try by changing |v.parentNode.removeChild(v)| to
> |removeNodeAndSource(v)| and reverting the change in bug 1024535 to see if
> that solve the mysterious error event on Windows.

Sorry, you can't revert the change in bug 1024535 for removeNodeAndSource() will set an empty string to the src attribute which will also trigger an error event.

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Chris Pearce (:cpearce) from comment #4)
> Do you see any assertions/warnings in the logs? Sometimes we hit this path
> on Windows:
> http://mxr.mozilla.org/mozilla-central/source/content/media/wmf/WMFReader.
> cpp#526
> 
> When we return failure here, it causes an "error" event to be dispatched to
> JS.

Wait, since the file is loaded via a <source> element, any decoding error should be dispatched the source element instead of bubbling up to the parent media element, right?

Comment 9

[Martijn Wargers (dead)]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #5)
> Unfortunately, I wasn't able to build a debug build on my Windows 7 VM, only
> opt, something with the xul.dll size or something, iirc.
> I'll just recreate test_load_candidates.html and start from there (tomorrow,
> though).

Ok, I can reproduce with the same source as test_load_candidates.html, but I have to also run the mochitests before in the mochitest.ini list, otherwise I can't reproduce. That makes it more time-consuming to minimize this.