Closed Bug 680518 Opened 13 years ago Closed 13 years ago

progress element display:block update issue


(Core :: Layout: Form Controls, defect)

Not set



Tracking Status
firefox5 --- unaffected
firefox6 --- wontfix
firefox7 --- wontfix
firefox8 --- fixed
firefox9 --- fixed


(Reporter: fkooman, Assigned: mounir)



(Keywords: testcase, Whiteboard: [qa!])


(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

Use the new HTML5 progress element and added style for the progress element:

progress {
  display: block;

(Used demo from

Tested with nightly Linux 64-bit Intel Built on 19-Aug-2011.

Actual results:

Using Firefox 6 (and later also nightly 64 bit from 19-Aug-2011):

- Progress bar is nicely updated on Mac OS X
- Progress bar does not update on Linux and Windows

(The progress bar does update on Linux and Windows when the Firefox window gets resized (manually).

Expected results:

Progress bar should also update on Linux and Windows.

Work around: remove the display: block style.
Component: DOM: CSS Object Model → Layout: Form Controls
QA Contact: style-system → layout.form-controls works fine for me (ticks up each second) on 64-bit Linux, on both 6.0 release and on nightly.
The demo url is wfm with Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 SeaMonkey/2.6a1
Yes, the demo works as intended. The problem starts to occur once you add the style:

progress {
  display: block;

To the CSS of the page.
Please attach a standalone testcase to the bug.  The demo requires other resources on your site (jQuery).
Actually, never mind; it looks like it just includes jQuery but doesn't actually need it; I'll attach.
Attached file reporter's testcase with the on-site jQuery links at the bottom removed, and with progress { display: block } added.
Confirmed on Linux.
Ever confirmed: true
Another related? layout bug with the progress element. The progress bar flows out of its table cell if no explicit width is specified. 

Works fine on: Google Chrome Dev channel and Webkit nightly (Mac OS X)
Fails on Firefox 6 (Mac OS X), Firefox 64 bit Nightly on Linux...
Attachment #554641 - Attachment mime type: text/plain → text/html
OS: Mac OS X → All
Hardware: x86 → All
(In reply to F. Kooman from comment #8)
> Created attachment 554641 [details]
> progress element in table flows out of column
> Another related? layout bug with the progress element. The progress bar
> flows out of its table cell if no explicit width is specified. 
> Works fine on: Google Chrome Dev channel and Webkit nightly (Mac OS X)
> Fails on Firefox 6 (Mac OS X), Firefox 64 bit Nightly on Linux...

Could you open another bug for that? I do not think this is related to the original issue.
Another bug opened as requested for the progress element flowing out of the table cell:
So, usually, progress bars have two elements: the container and the bar itself. This is not the case when using the MacOS X native rendering: the container draws the bar. If it works on MacOS X and not on other platforms, the reason must be related to that.

I thought maybe the frame wasn't reflowed correctly but both are according to my testings. I thought reflowing was invalidating the frames and when the frame was invalidated it was repainted but I guess I must be wrong, otherwise it would be working as expected :)
David, do you have any hints about what might be happening?
Yeah, something needs to invalidate something.  I think roc remembers the rules.  (When it's inline, blocks tend to invalidate a lot, so the bug was being hidden.)
The basic rules are:
-- if the parent frame moves the child, it must completely invalidate the old and new overflow areas
-- if the parent frame resizes the child without moving it, it must completely invalidate the difference between the old and new border-boxes
Probably the best thing to do is, whenever something changes that could affect the result of GetPosition, just invalidate the entire nsProgressFrame.
Attached patch Patch v1Splinter Review
Roc, thank you for the explanations. I think this patch corresponds to what you did recommend and fixes this issue.
Assignee: nobody → mounir
Attachment #554803 - Flags: review?(roc)
Keywords: testcase
Whiteboard: [needs review][needs branch]
Flags: in-testsuite+
Whiteboard: [needs review][needs branch] → [inbound][needs branch]
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound][needs branch] → [needs branch]
Target Milestone: --- → mozilla9
Comment on attachment 554803 [details] [diff] [review]
Patch v1

This is web facing so it would be great to have this pushed to aurora to reduce the amount of time this bug will be visible.
In addition. it's really non-risky.
Attachment #554803 - Flags: approval-mozilla-aurora?
Whiteboard: [needs branch]
Comment on attachment 554803 [details] [diff] [review]
Patch v1

Approved for aurora, assuming that we triple check that the added invalidation didn't move any of our performance needles (I wouldn't expect this to be a hot path on pageload, but I am also not a layout hacker)
Attachment #554803 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
François, and other interested, the fix is going to happen in Firefox 8 which is going to be released in about 3 months.
Sorry for the inconvenience.
Target Milestone: mozilla9 → mozilla8
Blocks: 686886
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111003 Firefox/9.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111002 Firefox/10.0a1

Verified in Firefox 8,9,10 on Ubuntu 11.04, Mac OS 10.6, Windows Xp and Windows 7 using the two test cases provided in the attachments.

The progress block is displayed as expected and the the table no longer flows out of the column.
Whiteboard: [qa!]
You need to log in before you can comment on or make changes to this bug.