Bug 70134

Summary:

Cues should be loaded by the cached resource loader

Product:

WebKit

Reporter:

Eric Carlson <eric.carlson>

Component:

Media

Assignee:

Eric Carlson <eric.carlson>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

annacc, ap, dglazkov, gustavo.noronha, gustavo, munna1991vikram, webkit-bug-importer, webkit.review.bot, xan.lopez

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

43668

Attachments:

Description	Flags
Part 1: Update CachedResourceLoader to load cues	none
Part 2: Implement the cue loader	none
Patch with ChangeLog	webkit.review.bot: commit-queue-
Add new file to other build systems.	darin: review+

Eric Carlson

Reported Friday, October 14, 2011 8:44:50 PM UTC

Cues should be cached like other web resources so they should be loaded by a CachedResourceLoader

Attachments
Part 1: Update CachedResourceLoader to load cues (17.79 KB, patch) 2011-10-14 12:46 PDT, Eric Carlson	no flags	Details Formatted Diff Diff
Part 2: Implement the cue loader (11.40 KB, patch) 2011-10-14 12:47 PDT, Eric Carlson	no flags	Details Formatted Diff Diff
Patch with ChangeLog (19.72 KB, patch) 2011-10-15 23:06 PDT, Eric Carlson	webkit.review.bot: commit-queue-	Details Formatted Diff Diff
Add new file to other build systems. (21.43 KB, patch) 2011-10-16 09:43 PDT, Eric Carlson	darin: review+	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Radar WebKit Bug Importer

Comment 1 Friday, October 14, 2011 8:45:03 PM UTC

<rdar://problem/10288601>

Eric Carlson

Comment 2 Friday, October 14, 2011 8:46:42 PM UTC

Created attachment 111056 [details] Part 1: Update CachedResourceLoader to load cues

Eric Carlson

Comment 3 Friday, October 14, 2011 8:47:25 PM UTC

Created attachment 111057 [details] Part 2: Implement the cue loader

WebKit Review Bot

Comment 4 Friday, October 14, 2011 9:38:59 PM UTC

Comment on attachment 111057 [details] Part 2: Implement the cue loader Attachment 111057 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10060651

Eric Carlson

Comment 5 Friday, October 14, 2011 9:45:18 PM UTC

(In reply to comment #4) > (From update of attachment 111057 [details]) > Attachment 111057 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/10060651 Part 2 depends on Part 1.

Collabora GTK+ EWS bot

Comment 6 Saturday, October 15, 2011 7:22:51 AM UTC

Comment on attachment 111057 [details] Part 2: Implement the cue loader Attachment 111057 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10074211

Eric Carlson

Comment 7 Saturday, October 15, 2011 6:47:50 PM UTC

(In reply to comment #6) > (From update of attachment 111057 [details]) > Attachment 111057 [details] did not pass gtk-ews (gtk): > Output: http://queues.webkit.org/results/10074211 See comment #5.

Eric Carlson

Comment 8 Saturday, October 15, 2011 9:48:59 PM UTC

Comment on attachment 111057 [details] Part 2: Implement the cue loader Clearing flags, this won't compile without the other patch so I will create a new bug for this once the other changes land.

Eric Carlson

Comment 9 Sunday, October 16, 2011 7:06:47 AM UTC

Created attachment 111176 [details] Patch with ChangeLog

WebKit Review Bot

Comment 10 Sunday, October 16, 2011 7:42:44 AM UTC

Comment on attachment 111176 [details] Patch with ChangeLog Attachment 111176 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10074465

Collabora GTK+ EWS bot

Comment 11 Sunday, October 16, 2011 8:12:15 AM UTC

Comment on attachment 111176 [details] Patch with ChangeLog Attachment 111176 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10073548

Eric Carlson

Comment 12 Sunday, October 16, 2011 5:43:26 PM UTC

Created attachment 111181 [details] Add new file to other build systems.

Darin Adler

Comment 13 Monday, October 17, 2011 8:01:37 PM UTC

Comment on attachment 111181 [details] Add new file to other build systems. View in context: https://bugs.webkit.org/attachment.cgi?id=111181&action=review > Source/WebCore/loader/cache/CachedCues.cpp:53 > + setEncodedSize(m_data.get() ? m_data->size() : 0); Should not need a "get" here. > Source/WebCore/loader/cache/CachedCues.cpp:56 > + while (CachedResourceClient *client = walker.next()) The "*" needs to be next to the type here. > Source/WebCore/loader/cache/CachedCues.h:43 > + virtual void data(PassRefPtr<SharedBuffer> data, bool allDataReceived); Can this be private?

Eric Carlson

Comment 14 Monday, October 17, 2011 8:23:07 PM UTC

http://trac.webkit.org/changeset/97637

Eric Carlson

Comment 15 Monday, October 17, 2011 8:23:42 PM UTC

(In reply to comment #13) > (From update of attachment 111181 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=111181&action=review > > > Source/WebCore/loader/cache/CachedCues.cpp:53 > > + setEncodedSize(m_data.get() ? m_data->size() : 0); > > Should not need a "get" here. > > > Source/WebCore/loader/cache/CachedCues.cpp:56 > > + while (CachedResourceClient *client = walker.next()) > > The "*" needs to be next to the type here. > > > Source/WebCore/loader/cache/CachedCues.h:43 > > + virtual void data(PassRefPtr<SharedBuffer> data, bool allDataReceived); > > Can this be private? I missed these comments, but will do the suggested cleanup in another patch.

Note You need to log in before you can comment on or make changes to this bug.