The default bug view has changed. See this FAQ.

progress element display:block update issue

VERIFIED FIXED in Firefox 8

Status

()

Core
Layout: Form Controls
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: François Kooman, Assigned: mounir)

Tracking

({testcase})

Trunk
mozilla8
testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox5 unaffected, firefox6 wontfix, firefox7 wontfix, firefox8 fixed, firefox9 fixed)

Details

(Whiteboard: [qa!])

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
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 http://thebrowsereview.com/demos/progress/progress.html).

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
http://thebrowsereview.com/demos/progress/progress.html 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
(Reporter)

Comment 3

6 years ago
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.
Created attachment 554604 [details]
reporter's testcase

http://thebrowsereview.com/demos/progress/progress.html with the on-site jQuery links at the bottom removed, and with progress { display: block } added.
Confirmed on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 8

6 years ago
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...
(Reporter)

Updated

6 years ago
Attachment #554641 - Attachment mime type: text/plain → text/html
(Assignee)

Updated

6 years ago
status-firefox5: --- → unaffected
status-firefox6: --- → affected
status-firefox7: --- → affected
status-firefox8: --- → affected
status-firefox9: --- → affected
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Comment 9

6 years ago
(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.
(Reporter)

Comment 10

6 years ago
Another bug opened as requested for the progress element flowing out of the table cell: https://bugzilla.mozilla.org/show_bug.cgi?id=680747
(Assignee)

Comment 11

6 years ago
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.
(Assignee)

Comment 15

6 years ago
Created attachment 554803 [details] [diff] [review]
Patch v1

Roc, thank you for the explanations. I think this patch corresponds to what you did recommend and fixes this issue.
Assignee: nobody → mounir
Status: NEW → ASSIGNED
Attachment #554803 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Keywords: testcase
Whiteboard: [needs review][needs branch]
Attachment #554803 - Flags: review?(roc) → review+
(Assignee)

Updated

6 years ago
Flags: in-testsuite+
Whiteboard: [needs review][needs branch] → [inbound][needs branch]
(Assignee)

Comment 16

6 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/4b1410af17c7
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound][needs branch] → [needs branch]
Target Milestone: --- → mozilla9
(Assignee)

Updated

6 years ago
status-firefox9: affected → fixed
(Assignee)

Comment 17

6 years ago
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?
(Assignee)

Updated

6 years ago
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+
(Assignee)

Comment 19

6 years ago
Pushed to Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/d6ce33ded6a1
status-firefox6: affected → wontfix
status-firefox7: affected → wontfix
status-firefox8: affected → fixed
(Assignee)

Comment 20

6 years ago
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
(Assignee)

Updated

6 years ago
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.
Status: RESOLVED → VERIFIED
Whiteboard: [qa!]
You need to log in before you can comment on or make changes to this bug.