[Webkit-unassigned] [Bug 84885] [Resource Timing] Implement buffer limits

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 7 15:50:50 PDT 2012


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





--- Comment #10 from James Simonsen <simonjam at chromium.org>  2012-09-07 15:51:05 PST ---
View in context: https://bugs.webkit.org/attachment.cgi?id=161955&action=review

> Source/WebCore/page/Performance.cpp:54
> +    m_resourceTimingBufferSize = defaultResourceTimingBufferSize;

This should be in the initializer list.

> Source/WebCore/page/Performance.cpp:154
> +        dispatchEvent(Event::create(eventNames().webkitresourcetimingbufferfullEvent, false, false));

This event is only supposed to fire once when it becomes full, not on every resource that arrives after it's full.

If the user clears the buffer during the event, then we should go ahead and record this resource.

I started a thread about this on web-perf. My goal for the thread was to fire the event after append() makes it full.

> Source/WebCore/page/Performance.h:99
> +    static const size_t defaultResourceTimingBufferSize = 150;

This doesn't need to be in the .h file.

> LayoutTests/http/tests/w3c/webperf/proposal/resource-timing/test_resource_timing_buffer_size_restriction.html:8
> +            performance.webkitSetResourceTimingBufferSize(2);

2 -> buffer_size

> LayoutTests/http/tests/w3c/webperf/proposal/resource-timing/test_resource_timing_on_resource_timing_buffer_full.html:24
> +                test_greater_than(count, 0, "onresourcetimingbufferfull should have been invoked!");

It should only happen once.

> LayoutTests/http/tests/w3c/webperf/proposal/resource-timing/test_resource_timing_on_resource_timing_buffer_full.html:33
> +</html>

We need more test cases. For instance, if you shrink the buffer size, it shouldn't modify the buffer until clear is called. Also, something that reads and clears the buffer during the callback.

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


More information about the webkit-unassigned mailing list