<audio controls> progress area causes the controls to display over content (Audio resizes itself)

RESOLVED WORKSFORME

Status

()

Toolkit
Video/Audio Controls
RESOLVED WORKSFORME
8 years ago
5 years ago

People

(Reporter: Michael A. Puls II, Unassigned)

Tracking

(Depends on: 1 bug, {regression, testcase})

unspecified
x86
Windows XP
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100105 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100105 Minefield/3.7a1pre (.NET CLR 3.5.30729)

Test the following (will attach):

<!DOCTYPE html>
<html>
    <head>
        <title></title>
        <style>
            audio {
                width: 300px;
                height: 15px;
            }
        </style>
    <body>
        <p><audio controls=""></audio></p>
        <ol>
            <li><a href="">Track 1</a></li>
        </ol>
    </body>
</html>

In Opera (10.5 pre-alphas) and Safari + latest webkit, the controls display fine.
 
However, in Firefox, a loading/progress area shoots out the top of the controls. When doing this, it causes the controls to shift down and display over the top of the playlist. I would expect this to increase the height of the <p> instead so that the <ol> just shifts down.

Also note that in this specific case (no @src or anything), I don't see how the progress area is even useful. Just seem annoying imo. Opera and Safari, as of right now at least, don't have this pop-out progress area.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
Created attachment 420255 [details]
Attaching an example
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm not sure what's going on.
Keywords: testcase
This regressed in m-c nightlies between 2009-10-30-06 and 2009-10-31-04, that's in this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-10-30+06&enddate=2009-10-31+04

If I backout dolske's checkin for bug 520614, the problem goes away; it's a regression from bug 520614.
Blocks: 520614
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio

Comment 4

8 years ago
If you don't set "hight" for <audio>, the control jumps around after the first load and increases it's hight unnecessarily if [►] is pressed again.
Example (from bug 560910) is here:

http://www.elektronotdienst-nuernberg.de/bugs/tel-audio.html

That's a layout-destroying regression from 1.9.2.
blocking2.0: --- → ?
Keywords: regression

Updated

8 years ago
Duplicate of this bug: 548460
blocking2.0: ? → beta1+

Comment 6

8 years ago
on Bug 548460 i attached a screenshot showing the problem https://bug548460.bugzilla.mozilla.org/attachment.cgi?id=428844
and made that suggestion : "Maybe that the throbber could show up instead of the duration while loading and then be replaced with duration, since duration brings no information while loading (0:00)"

Updated

8 years ago
Duplicate of this bug: 572320

Comment 8

8 years ago
Changed summary, may be easier to find
Summary: <audio controls> progress area gets in the way and causes the controls to display over content → <audio controls> progress area causes the controls to display over content (Audio resizes itself)
--> dolske, but he may reassign as he sees fit! Looks like it might be a good bug for someone newer to the project to take in order to learn the wonders/horrors of XBL!
Assignee: nobody → dolske
blocking2.0: beta1+ → final+

Updated

8 years ago
Duplicate of this bug: 577989

Updated

8 years ago
Duplicate of this bug: 503143
I have a patch in bug 604885 which changes the audio and video elements so that their content is clipped at the css-specified dimensions. So when you set the width and height using css to be insufficient to show the controls UI, it will clip off the bits which don't fit inside the css-specified dimension. That should resolve this bug.
Depends on: 604885
Assignee: dolske → fryn

Comment 13

7 years ago
This WFM now, but it's not a blocker in any case.
Status: NEW → RESOLVED
blocking2.0: final+ → -
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Probably fixed by bug 604885.

Updated

7 years ago
Blocks: 619421

Comment 15

7 years ago
The progress area no long displays over content, but it still displays in a separate box from the other controls, often enlarging the element. It should be merged into the regular controls region.

I filed bug 619421 for this.
Depends on: 620317

Updated

7 years ago
Assignee: fryn → nobody
You need to log in before you can comment on or make changes to this bug.