Closed
Bug 680518
Opened 14 years ago
Closed 13 years ago
progress element display:block update issue
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
mozilla8
Tracking | Status | |
---|---|---|
firefox5 | --- | unaffected |
firefox6 | --- | wontfix |
firefox7 | --- | wontfix |
firefox8 | --- | fixed |
firefox9 | --- | fixed |
People
(Reporter: fkooman, Assigned: mounir)
References
Details
(Keywords: testcase, Whiteboard: [qa!])
Attachments
(3 files)
2.00 KB,
text/html; charset=UTF-8
|
Details | |
523 bytes,
text/html
|
Details | |
3.03 KB,
patch
|
roc
:
review+
johnath
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
Comment 2•14 years ago
|
||
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•14 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.
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•13 years ago
|
||
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•13 years ago
|
Attachment #554641 -
Attachment mime type: text/plain → text/html
Assignee | ||
Updated•13 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•13 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•13 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•13 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•13 years ago
|
||
Roc, thank you for the explanations. I think this patch corresponds to what you did recommend and fixes this issue.
Attachment #554803 -
Flags: review?(roc) → review+
Assignee | ||
Updated•13 years ago
|
Flags: in-testsuite+
Whiteboard: [needs review][needs branch] → [inbound][needs branch]
Assignee | ||
Comment 16•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound][needs branch] → [needs branch]
Target Milestone: --- → mozilla9
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 17•13 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•13 years ago
|
Whiteboard: [needs branch]
Comment 18•13 years ago
|
||
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•13 years ago
|
||
Pushed to Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/d6ce33ded6a1
Assignee | ||
Comment 20•13 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
Comment 21•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [qa!]
You need to log in
before you can comment on or make changes to this bug.
Description
•