RESOLVED FIXED 30343
[v8] typeof(HTMLMediaElement) should return undefined if media engine is not available
https://bugs.webkit.org/show_bug.cgi?id=30343
Summary [v8] typeof(HTMLMediaElement) should return undefined if media engine is not ...
Hin-Chung Lam
Reported 2009-10-13 15:06:26 PDT
In Chromium: 1. Remove all ffmpeg library files 2. Run Chromium 3. Open a page and does typeof(HTMLMediaElement), it should return undefined, but it returns "function" instead. In the v8 binding we should check if the media engine and intercept such calls and returns undefined.
Attachments
Patch (1.80 KB, patch)
2009-10-13 16:27 PDT, Hin-Chung Lam
eric: review-
patch (3.19 KB, patch)
2009-10-15 12:59 PDT, Hin-Chung Lam
no flags
Patch + manual test case (6.06 KB, patch)
2009-10-15 17:25 PDT, Hin-Chung Lam
dglazkov: review+
dglazkov: commit-queue-
Hin-Chung Lam
Comment 1 2009-10-13 16:27:17 PDT
Created attachment 41138 [details] Patch This patch passes try servers on chromium side.
Eric Seidel (no email)
Comment 2 2009-10-15 12:02:23 PDT
Comment on attachment 41138 [details] Patch Every change requires a test: "No new test because this is V8 specific." makes no sense.
Hin-Chung Lam
Comment 3 2009-10-15 12:59:01 PDT
Created attachment 41240 [details] patch Providing a manual test.
Eric Seidel (no email)
Comment 4 2009-10-15 13:44:30 PDT
OK. I misunderstood how one would reproduce this. I guess I didn't read the bug close enough. Yes, I think it's better to have the manual test, but I now understand why you didn't have a test initially. It would also of course be possible to override MediaPlayer::isAvailable() via some layoutTestController method, but a manual test is OK in this case. I think a v8-enabled reviewer should review this though.
Dimitri Glazkov (Google)
Comment 5 2009-10-15 13:47:43 PDT
Didn't atwilson just do this?
Andrew Wilson
Comment 6 2009-10-15 13:59:40 PDT
I changed window.Audio, and did nothing for HTMLMediaElement or any other constructors, as I was not aware that this was the desired behavior. Just returning undefined for the constructor is incorrect - you should instead follow the example for window.Audio, which actually removes the associated attribute from the window object. Case in point: with the patch attached to this bug, "typeof HTMLMediaElement === 'undefined'", but "'HTMLMediaElement' in window" would still return true. If you follow the approach I used for window.Audio, then you'd get the correct behavior in both cases. Take a look here: https://bugs.webkit.org/show_bug.cgi?id=30240
Hin-Chung Lam
Comment 7 2009-10-15 14:02:01 PDT
Great, I'll also change the tests accordingly.
Hin-Chung Lam
Comment 8 2009-10-15 17:25:01 PDT
Created attachment 41254 [details] Patch + manual test case
Hin-Chung Lam
Comment 9 2009-10-16 14:15:45 PDT
I've uploaded a new patch does similar things according to atwilson. Please take a look. Thanks.
Andrew Wilson
Comment 10 2009-10-16 15:37:13 PDT
This looks fine to me (although someone with reviewer bit needs to r+ it) - only comment is that ideally the test would include testing that ('HTMLMediaElement' in window) == false.
Dimitri Glazkov (Google)
Comment 11 2009-10-19 12:16:12 PDT
Comment on attachment 41254 [details] Patch + manual test case > + attribute [Conditional=VIDEO,EnabledAtRuntime] HTMLAudioElementConstructor HTMLAudioElement; > + attribute [Conditional=VIDEO,EnabledAtRuntime] HTMLMediaElementConstructor HTMLMediaElement; > + attribute [Conditional=VIDEO,EnabledAtRuntime] HTMLVideoElementConstructor HTMLVideoElement; > + attribute [Conditional=VIDEO,EnabledAtRuntime] MediaErrorConstructor MediaError; Space between IDL attributes would be nice for readability. You can fix upon landing.
Hin-Chung Lam
Comment 12 2009-10-19 17:00:03 PDT
Note You need to log in before you can comment on or make changes to this bug.