[Webkit-unassigned] [Bug 25267] New: Autobuffer on <audio /> cannot be disabled

[bugzilla-daemon at webkit.org]

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

           Summary: Autobuffer on <audio /> cannot be disabled
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: webkit.web at horizon-nigh.org


Scenario:
I have a podcast, and an archive page that provides for a user to listen to
many podcast entries (let's say a dozen). Each one has an associated audio
player using the HTML5 <audio /> tag. It is likely that a user who visits this
page will only listen to a small fraction of the available audio files (or none
at all).

Result:
Using WebKit, upon first navigating to the page, the complete data for all 12
audio files is downloaded before the user interacts with them at all. Our
bandwidth use would go through the roof, and the user may not appreciate it
either (maybe they're on Comcast).

Cause:
HTML5 indicates this element has an 'autobuffer' attribute, but only defines
behaviour when it is present or 'true'. Apparently, it is not possible in HTML5
to indicate that a boolean attribute should be false except by its absence.
Neither omitting the attribute nor setting it to 'false' has the desired result
of preventing automatic downloading.

Indeed, the spec does indicate '[t]his attribute may be ignored altogether',
but as WebKit is the leading implementor of HTML5 so far, I would be
comfortable trusting its implementation for now.

Change needed:
Only autobuffer an audio element when the autobuffer attribute is specified
and/or true. Alternatively, provide some other way to disable the autobuffer
behaviour.

Workaround 1:
Initially load a temporary element that instructs the user to 'click to begin
playing', and use JavaScript to replace it with an <audio /> tag once they do.
This breaks when JS is not enabled, and also is not instantly recognisable to
the user as their browser's native audio player.

Workaround 2:
Use an Adobe Flash widget. This is a leading cause of unhappiness amongst
standards-compliant web devs.


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