Edgewall Software
Modify

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#1886 closed defect (fixed)

Progress bar layout of Milestone is invalid.

Reported by: anonymous Owned by: Christian Boos
Priority: normal Milestone: 0.9
Component: roadmap Version: devel
Severity: minor Keywords: layout
Cc: Branch:
Release Notes:
API Changes:

Description

Hi. all.
I used Trac-0.9pre revision 2053.

If the number of tickets(closed and active) of milestone is same, Progress bar layout is not wrong.

For example

In proper case.

closed tickets active tickets

In wrong case.

closed tickets (blank)
active tickets (blank)

Attachments (2)

capture.bmp (226.7 KB ) - added by anonymous 14 years ago.
capture image.
ie6-1.jpg (14.7 KB ) - added by markus 14 years ago.

Download all attachments as: .zip

Change History (16)

by anonymous, 14 years ago

Attachment: capture.bmp added

capture image.

comment:1 by Christopher Lenz, 14 years ago

Priority: normallow
Severity: normalminor
Status: newassigned

comment:2 by anonymous, 14 years ago

This problem appears in IE and Mathon, not FireFox.

comment:3 by asmodai@…, 14 years ago

Which version of IE did you test this with?

comment:4 by markus, 14 years ago

The screenshot is most likely an image of IE6, because it looked the same when I tried to reproduce the problem.

Note that there's a problem with Firefox, too. When IE displays the progress bar like in the screenshot, Firefox cuts the right border of it.

So, to me this does not seem like a browser bug. It looks more like the widths of the inner divs are bigger than the width of the outer div. While IE puts the second inner div in a new line, Firefox draws it on top of the outer div and so paints over its right border. However, this seems to depend on the relation between closed and active tickets as it is not always reproducible.

comment:5 by markus, 14 years ago

For the record: With the latest versions (from trunk) I've never seen a milestone layout like the one in anonymous' screenshot. Unfortunately the layout in IE is still bad, when the progress bar is the topmost (next to the Show already completed milestones box). I'll attach a screenshot.

by markus, 14 years ago

Attachment: ie6-1.jpg added

comment:6 by jan, 14 years ago

The invalid layout still exist with IE in Trac 0.9b2!

comment:7 by Christian Boos, 14 years ago

Owner: changed from Christopher Lenz to Christian Boos
Priority: lownormal
Status: assignednew

It seems that, for some reason, the floating blocks constituting the progress bar behave as if they sometimes get a clear: left constraint, in IE. Forcing that property to be none won't work, but forcing it to right does the trick.

This addresses the problem examplified by attachment:capture.bmp

The other problem, visible on Trac's Roadmap (attachment:ie6-1.jpg) can't be reproduced, and is likely due to the presence of the IFRAME of Google ads (saving that /roadmap page with Firefox, then viewing it with IE will show correct interaction between the progress floating block and the prefs floating block)

  • roadmap.css

     
    55 border: none;
    66 display: block;
    77 float: left;
     8 clear: right;
    89 height: 1.2em;
    910}
    1011div.progress :link:hover, div.progress :visited:hover { background: #fff }

comment:8 by Christian Boos, 14 years ago

After some further investigations, it appears that the intermittent stacking of the floating blocks is due to the rule 7.

A left-floating box that has another left-floating box to its left may not have its right outer edge to the right of its containing block's right edge.

For some reasons, IE thinks that 50% + 50% will exceed 100%… That's why it works well when the sum isn't 100% (e.g. the 1/3, 2/3 case).

Therefore, an alternative fix would be:

  • roadmap.cs

     
    4646         if:#stats.total_tickets != #1 ?>s<?cs /if ?> closed"></a>
    4747       <a class="open" href="<?cs
    4848         var:milestone.queries.active_tickets ?>" style="width: <?cs
    49          var:#stats.percent_active ?>%" title="<?cs
     49         var:#stats.percent_active - 1 ?>%" title="<?cs
    5050         var:#stats.active_tickets ?> of <?cs
    5151         var:#stats.total_tickets ?> ticket<?cs
    5252         if:#stats.total_tickets != #1 ?>s<?cs /if ?> active"></a>
  • milestone.cs

     
    126126        if:#stats.total_tickets != #1 ?>s<?cs /if ?> closed"></a>
    127127      <a class="open" href="<?cs
    128128        var:milestone.queries.active_tickets ?>" style="width: <?cs
    129         var:#stats.percent_active ?>%" title="<?cs
     129        var:#stats.percent_active - 1 ?>%" title="<?cs
    130130        var:#stats.active_tickets ?> of <?cs
    131131        var:#stats.total_tickets ?> ticket<?cs
    132132        if:#stats.total_tickets != #1 ?>s<?cs /if ?> active"></a>

comment:9 by Christian Boos, 14 years ago

Status: newassigned

I just noticed that the above trick was already used for the progress bars shown in the milestone stats, so this is probably the way to go…

comment:10 by trac@…, 14 years ago

The above trick is already being used for the progress bars, but I do not think that is the way to go. It would be much preferable to use css to get it correct than to hack the percentages due to a bug in IE. Hacking the percentages already causes other problems because they do not add to 100% anymore (like the width of the percent_active bar no longer being correct).

I was looking at correcting this in my implementation of milestone stat extension points, which I am nearly finished (This is the last issue I was going to solve before submitting it).

— Justin

comment:11 by Christian Boos, 14 years ago

I don't think it's a big deal, as the percent_active value is not presented as such to the user but only used for the visual cue. Do you simply favor using the clear: right trick, or do you have a better solution?

(Also, I checked the 1/3 closed and 2/3 opened situation, the percentages are 33% and 67%, so no idea why it works in this case and not for the 50%/50% case)

comment:12 by Christopher Lenz, 14 years ago

cboos proposed fix looks good IMHO. The difference between a width of 49% and 50% shouldn't be noticable visually.

comment:13 by Christian Boos, 14 years ago

Resolution: fixed
Status: assignedclosed

Fixed by r2411.

Justin, feel free to come up with a better alternative for a later milestone… The fix is good enough for 0.9.

comment:14 by trac@…, 14 years ago

I agree it is a good solution for 0.9. I explored another way of doing it for my milestone extension point changes by simulating a border using background-color and 1 pixel padding, but the results were inconsistent. Instead I guess I will use the same solution, except make it more specific to apply only in the case of 50%/50%.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.