bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

REOPENED
Unassigned

Status

()

Core
Audio/Video: Playback
REOPENED
4 years ago
a year ago

People

(Reporter: Martijn Wargers (zombie), Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
Created attachment 8475286 [details] [diff] [review]
1055579_mochitest.diff

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

Comment 2

4 years ago
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.
(Reporter)

Comment 3

4 years ago
Created attachment 8475317 [details] [diff] [review]
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.
Attachment #8475286 - Attachment is obsolete: true
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?
(Reporter)

Comment 5

4 years ago
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).
(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.
Flags: needinfo?(martijn.martijn)
(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.
(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?
(Reporter)

Comment 9

4 years ago
(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.
Flags: needinfo?(martijn.martijn)
Component: Audio/Video → Audio/Video: Playback
(Reporter)

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.