Closed
Bug 488084
Opened 15 years ago
Closed 15 years ago
video volume slider not displayed in correct position
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: Dolske, Assigned: enndeakin)
References
Details
(Keywords: fixed1.9.1)
Attachments
(1 file)
(deleted),
patch
|
neil
:
review+
neil
:
superreview+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
From bug 475317 comment 12: Enn: I'm hitting a weird bug... Start playing a video, then click the mute button. The volume slider should move to the bottom (0), but it stays at the top (100). Now move the mouse away (so the controls fade out), then back over and... ta-da, the volume slider is now being drawn at the correct position. Further clicks on the mute button make the volume <scale> work normally. The immediate cause of this is that the CurrentPositonChanged() code in nsSliderFrame is hitting the "do nothing if the position did not change" case, and bails out (curpospx is 0, instead of the expected 100). The real problem occurs earlier on... Calls to _setIntegerAttribute() in scale.xul and calls to nsSliderFrame::AttributeChanged() should occur in pairs. But I'm not seeing the call to AttributeChanged() when the scale's value is set from the video control's setupInitialState(), nor does it get called when I hardcode <scale value="50"> in the XUL. The code in _setIntegerAttribute() is calling setAttribute() in all these cases, so I'm not sure where things are going wrong early on.
Assignee | ||
Comment 1•15 years ago
|
||
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Reporter | ||
Comment 2•15 years ago
|
||
Yep, this fixes the problem for me.
Assignee | ||
Updated•15 years ago
|
Attachment #373912 -
Flags: superreview?(neil)
Attachment #373912 -
Flags: review?(neil)
Updated•15 years ago
|
Attachment #373912 -
Flags: superreview?(neil)
Attachment #373912 -
Flags: superreview+
Attachment #373912 -
Flags: review?(neil)
Attachment #373912 -
Flags: review+
Comment 3•15 years ago
|
||
Comment on attachment 373912 [details] [diff] [review] we just need to initialize mCurPos properly For consistency I guess you should read the curpos from a scrollbar if available, although given scrollbar.xml's extensive xbl:inherits list I fail to see why we read any attributes from the scrollbar...
Comment 4•15 years ago
|
||
I see we often need to set attributes on the scrollbar, so we usually have a choice of elements from which to read the attribute anyway.
Assignee | ||
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•15 years ago
|
Attachment #373912 -
Flags: approval1.9.1?
Reporter | ||
Updated•15 years ago
|
Whiteboard: [needs 1.9.1 landing]
Comment 5•15 years ago
|
||
Comment on attachment 373912 [details] [diff] [review] we just need to initialize mCurPos properly a191=beltzner
Attachment #373912 -
Flags: approval1.9.1? → approval1.9.1+
Reporter | ||
Comment 6•15 years ago
|
||
Pushed to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a0c5226d1ae0
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
You need to log in
before you can comment on or make changes to this bug.
Description
•