Closed Bug 538084 Opened 15 years ago Closed 14 years ago

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

Categories

(Toolkit :: Video/Audio Controls, defect)

Product:
Toolkit
Component:
Video/Audio Controls
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: shadow2531, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

Attaching an example
329 bytes, text/html
Details 
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
Attached file Attaching an example — 
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
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

    
    

    
  
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.
URL: http://www.elektronotdienst-nuernberg...
blocking2.0: --- → ?
Keywords: regression

    
    

    
  
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)"

    
    

    
  
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+

    
    

    
  
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

    
    

    
  
This WFM now, but it's not a blocker in any case.
Status: NEW → RESOLVED
blocking2.0: final+ → -
Closed: 14 years ago
Resolution: --- → WORKSFORME

    
  
Blocks: 619421

    
    

    
  
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.

    
  
Assignee: fryn → nobody

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: