Bug 85926 - [chromium] Support multiple buffered time ranges
Summary: [chromium] Support multiple buffered time ranges
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ami Fischman
URL:
Keywords:
Depends on:
Blocks: 85925
  Show dependency treegraph
 
Reported: 2012-05-08 15:53 PDT by Ami Fischman
Modified: 2012-05-09 10:02 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.41 KB, patch)
2012-05-08 16:37 PDT, Ami Fischman
no flags Details | Formatted Diff | Diff
Patch (2.79 KB, patch)
2012-05-09 09:13 PDT, Ami Fischman
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ami Fischman 2012-05-08 15:53:30 PDT
RenderMediaControlsChromium.cpp:paintMediaSlider() contains:
// FIXME: Draw multiple ranges if there are multiple buffered ranges.
(at http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderMediaControlsChromium.cpp&exact_package=chromium&q=file:WebKit%20file:chromium%20file:controls%20file:media%20-file:layouttests&type=cs&l=130)

Indeed, fixing chromium's pipeline code to return multiple buffered time ranges (instead of lying and claiming that if the latest buffered byte is at time t, we've buffered all of [0,t) even when a seek might have jumped over the majority of the bytes) results in bogus buffered-area painting, as the first X% of the slider bar is painted when X% of the resource is buffered, without being broken up by range.

This is step #1 of bug 85925.
Comment 1 Ami Fischman 2012-05-08 16:37:08 PDT
Created attachment 140810 [details]
Patch
Comment 2 Ami Fischman 2012-05-08 16:42:13 PDT
eric.carlson: mind taking a look?
Comment 3 Eric Seidel (no email) 2012-05-08 16:42:32 PDT
Comment on attachment 140810 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140810&action=review

> Source/WebCore/rendering/RenderMediaControlsChromium.cpp:146
> +        double fakePercentLoaded = bufferedTimeRanges->end(bufferedTimeRanges->length() - 1, ignoredException) / mediaElement->duration();

So this could cause JavaScript to execute?  And thus possibly invalidate pointers?
Comment 4 Ami Fischman 2012-05-08 16:49:06 PDT
(In reply to comment #3)
> (From update of attachment 140810 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=140810&action=review
> 
> > Source/WebCore/rendering/RenderMediaControlsChromium.cpp:146
> > +        double fakePercentLoaded = bufferedTimeRanges->end(bufferedTimeRanges->length() - 1, ignoredException) / mediaElement->duration();
> 
> So this could cause JavaScript to execute?  And thus possibly invalidate pointers?

I'm not sure.  I was cargo-culting from the definition of percentLoaded() itself (which was being called in the old version).
Are you saying this is a problem?
Comment 5 Eric Seidel (no email) 2012-05-08 16:52:22 PDT
Any time you have a method which returns an ExceptionCode, you need to be cautious of the fact that that method is a DOM method, and possibly causing JavaScript to execute.  In this case, that may not be relevant at all!  I don't know what that method looks like.  But seeing ExceptionCode does make me wonder.

Also, since you're ignoring that exception code, I believe we have a more modern way to do that which will ASSERT in Debug builds if the exception != 0.
Comment 6 Ami Fischman 2012-05-08 17:01:47 PDT
(In reply to comment #5)
> Any time you have a method which returns an ExceptionCode, you need to be cautious of the fact that that method is a DOM method, and possibly causing JavaScript to execute.  In this case, that may not be relevant at all!  I don't know what that method looks like.  But seeing ExceptionCode does make me wonder.
> 
> Also, since you're ignoring that exception code, I believe we have a more modern way to do that which will ASSERT in Debug builds if the exception != 0.

I think you mean ASSERT_NO_EXCEPTION.

I hope Eric Carlson can speak to whether there is an easy way to see that no exception can happen (and I'll use A_N_E) or whether we just don't care (and that HTMLMediaElement::percentLoaded() is reasonable to ignore exceptions).
Comment 7 Eric Seidel (no email) 2012-05-08 17:10:19 PDT
I'm really not trying to spread FUD here. :)  Just trying to make sure you're aware of the potential danger.  I suspect that this is not infact a method which can execute JavaScript. :)
Comment 8 Eric Carlson 2012-05-08 21:04:04 PDT
Comment on attachment 140810 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140810&action=review

>>> Source/WebCore/rendering/RenderMediaControlsChromium.cpp:146
>>> +        double fakePercentLoaded = bufferedTimeRanges->end(bufferedTimeRanges->length() - 1, ignoredException) / mediaElement->duration();
>> 
>> So this could cause JavaScript to execute?  And thus possibly invalidate pointers?
> 
> I'm not sure.  I was cargo-culting from the definition of percentLoaded() itself (which was being called in the old version).
> Are you saying this is a problem?

TimeRanges.end() will only return an exception when the index is out of bounds, which can't happen here. I can not cause script to execute.

Is it possible for this be called when duration is 0 or inf?
Comment 9 Ami Fischman 2012-05-09 09:13:50 PDT
Created attachment 140956 [details]
Patch
Comment 10 Ami Fischman 2012-05-09 09:14:14 PDT
(In reply to comment #8)
> Is it possible for this be called when duration is 0 or inf?

I'm not sure, but percentLoaded() guards against that, so now I do too.
Comment 11 WebKit Review Bot 2012-05-09 10:02:07 PDT
Comment on attachment 140956 [details]
Patch

Clearing flags on attachment: 140956

Committed r116539: <http://trac.webkit.org/changeset/116539>
Comment 12 WebKit Review Bot 2012-05-09 10:02:13 PDT
All reviewed patches have been landed.  Closing bug.