[Webkit-unassigned] [Bug 35327] New: supportsMuting() Should be internal interface between MediaPlayer and MediaPlayerPrivate
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Feb 23 21:40:05 PST 2010
https://bugs.webkit.org/show_bug.cgi?id=35327
Summary: supportsMuting() Should be internal interface between
MediaPlayer and MediaPlayerPrivate
Product: WebKit
Version: 528+ (Nightly build)
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: Normal
Priority: P2
Component: Media Elements
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: nicholas.young at nokia.com
CC: eric.carlson at apple.com
At the moment there is a bug with supportsMuting() under the following
scenario:
1. setMuted() is called on the HTMLMediaElement before the MediaPlayer is
constructed in loadResource().
m_muted in HTMLMediaElement is set to true, but nothing else of interest
happens.
2. The MediaPlayer is contructed during loadResource and updateVolume() is
called.
updateVolume() assumes that supportsMuting() == false, and sets the volume of
the MediaPlayer to 0 (because m_muted is true).
3. MediaPlayer loads a media engine which supports muting. Subsequent calls to
supportsMuting() will return true.
4. Attempting to unmute the media element at this point is unsuccessful.
MediaPlayer::m_muted changes, but MediaPlayer::m_volume is still zero.
This can be solved by making sure that HTMLMediaElement::updateVolume() checks
for supportsMuting(), and moving the call to updateVolume() in loadResource()
to after the call to load() (i.e. Media Engine Selection).
HOWEVER, I don't believe this is the correct solution. Why are we exposing
supportsMuting() to HTMLMediaElement at all?
This should be interface which exists only between MediaPlayer and
MediaPlayerPrivate.
Patch forthcoming.
--
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