Last Comment Bug 619421 - <audio controls> progress UI should be merged into controls (not enlarge the element)
: <audio controls> progress UI should be merged into controls (not enlarge the ...
Status: RESOLVED INCOMPLETE
:
Product: Toolkit
Classification: Components
Component: Video/Audio Controls (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.elektronotdienst-nuernberg...
: 548460 (view as bug list)
Depends on: 538084 620317
Blocks: 681553 672037 1068523
  Show dependency treegraph
 
Reported: 2010-12-15 11:52 PST by Frank Yan (:fryn)
Modified: 2016-01-25 07:52 PST (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Frank Yan (:fryn) 2010-12-15 11:52:27 PST
While the source for an <audio controls> element is loading, the throbber enlarges the element and displays in the same region that it does for a <video> element.

This progress UI should be merged into the regular controls UI, so that it does not temporarily enlarge the element.
Comment 1 antistress 2010-12-15 14:15:04 PST
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)"
Comment 2 j.j. 2010-12-15 20:36:43 PST
This destroys layout and should block.
Comment 3 Frank Yan (:fryn) 2010-12-15 20:39:13 PST
(In reply to comment #2)
> This destroys layout and should block.

This bug is the more destructive subset of bug 538084, which has both been fixed and marked not blocking. Therefore, this is also not blocking.
Comment 4 j.j. 2010-12-15 21:02:41 PST
Bug 538084 was blocking 2.0 until yesterday. Then it was resolved as WFM, probably overlooking *this* issue.
Comment 5 j.j. 2010-12-15 21:03:29 PST
*** Bug 548460 has been marked as a duplicate of this bug. ***
Comment 6 Frank Yan (:fryn) 2010-12-15 21:03:53 PST
(In reply to comment #4)
> Bug 538084 was blocking 2.0 until yesterday. Then it was resolved as WFM,
> probably overlooking *this* issue.

Why is this a regression?
Comment 7 j.j. 2010-12-15 21:24:28 PST
See bug 538084 comment 4
Comment 8 Chris Pearce (:cpearce) 2010-12-19 18:10:01 PST
I've filed bug 620317 to handle unnecessary enlargement of the audio element's controls, which is I think what j.j. is referring to.
Comment 9 antistress 2011-03-31 04:39:08 PDT
as far as i'm concerned, this bug is about the throbber enlarging the native audio player and disturbing the pages layout.
Now that Firefox 4 is out (great work and thanks for it by the way), is it possible to have a look at ihis bug ?
I've made a suggestion above (comment 1)
thanks !
Comment 10 Chris Pearce (:cpearce) 2011-03-31 15:02:32 PDT
(In reply to comment #9)
> as far as i'm concerned, this bug is about the throbber enlarging the native
> audio player and disturbing the pages layout.

This should be fixed by bug 620317, which just needs dolske to review the patch... dolske can you review that patch please, so I can land it on mozilla-central before the migration over to firefox-experimental, and we lose the chance to fix this for Firefox 5? The cutoff is on April 12 IIRC.
Comment 11 Frank Yan (:fryn) 2012-10-16 00:13:12 PDT
I'm pretty sure that we've fixed this.
Comment 12 Jared Wein [:jaws] (please needinfo? me) 2014-10-29 07:25:35 PDT
This wasn't fixed, it was just worked around by bug 698940. We still need a proper solution here.

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