[Webkit-unassigned] [Bug 66878] HTMLAudioElement can be garbage collected while it playing

Thu Oct 13 09:24:59 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=66878

--- Comment #39 from Eugene Nalimov <enal at google.com>  2011-10-13 09:24:58 PST ---
>Can't this be broken into two patches?

I thought about that. Problem is that I could not (easily) reproduce 2nd problem without 1st fix, I tried and then gave up. At lest now all changes are HTMLAudioElement-only.

I'll do that if you say I need, but I'd prefer to have one checkin that fixes HTML5 GC-related problems...

>Nit: Is there any reason to not have the script nodes in <head>?
>Nit: Indentation would make this file much more readable, IMO.

I did not invented test from scratch. I started from existing one, and modified it. I believe absolute majority of our tests following that pattern...

>Nit: is there any reason to have these in the global scope?

I have to have communicating callbacks (event functions), and I thought that just using globals would be simplest way. Here you don't need smart code, you need code that can be understood by average developer in 30 seconds...

>1. Why do you need a new audio file, can't you use silence.wav (it and all of the existing files with audio tracks purposely have encoded silence so a computer running layout tests doesn't make noise)? If it is too long, just seek to near the end before starting playback.

On specific file problem demonstrates itself much more often than on other files. Maybe that is exact timing, maybe something else, I tried silence.wav and decided I'd better check in file where problem happens 95% of times.

>2. findMediaFile() is only necessary when you have a multiple versions of a media file with different encodings.

All audio tests use that functions to open files, I decided to do that as well.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.