7418 - progressmeter needs better default width/height values

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Kathleen :Brade]

Given the following in a xul file, I would expect to see 4 progressmeters which
are about 100% the width or height of the window.  I wouldn't be surprised if the
progressmeters appeared in some default width / height (such as 15 pixels by 100
pixels).  I *am* surprised that they (essentially) don't appear at all.

<?xml version="1.0"?>
<?xml-stylesheet href="resource:/res/samples/xul.css" type="text/css"?>

<window xmlns:html="http://www.w3.org/TR/REC-html40"
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	width="300" height="300" onload="onLoad()">

 			  <progressmeter id="statusbar-icon" mode="normal" value="1" />
  <html:br/>
 			  <progressmeter id="undetermined.hprog"/>
  <html:br/>
			  <progressmeter id="vert.progress" value="1" align="vertical"/>
  <html:br/>
			  <progressmeter id="undeter.vprogress" value="1" align=
"horizontal"/>
</window>

Comment 1

[Eric Vaughan]

A few things. Number one there was an error in the setup of you xul file this
caused a problem. The second problem is you set the current value of the
progress meter to be 1. That means 1% so there it only draws 1 pixel of the bar.
This is compounded by the fact that the the style German has set up for the
progress meter has no borders and no background. So If you don't have a bar to
display you will see nothing. That is how the style is set up. Perhaps we should
at least have a border around it. The style also gives it a default height of
0.7em which is a rather small height. If this is not set the default height is
16pixels. German can you fix this in CSS? You set the height to be 0.7em but
what if the progress meter is vertical? I don't think you want its height to be
0.7em. You would want its width to be 0.7em instead. Try removint the height
definition in progress meter and then run the following test. See how it works
and then change the style rules to get what you want:

<?xml version="1.0"?>
<?xml-stylesheet href="xul.css" type="text/css"?>
<?xml-stylesheet href="navigator.css" type="text/css"?>

<!DOCTYPE window>

<window style="width: 100%; height: 100%"
xmlns:html="http://www.w3.org/TR/REC-html40"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        onConstruction="Startup()">

        <progressmeter mode="normal" value="50%" />
		<html:br/>
        <progressmeter id="undetermined.hprog"/>
        <html:br/>
        <progressmeter id="vert.progress" value="75%" align="vertical"/>
        <html:br/>
        <progressmeter id="undeter.vprogress" value="25%" align=
"horizontal"/>
</window>

Comment 2

[chris hofmann]

how critical is this for m7?

Comment 3

[chris hofmann]

move to m8 after conversation with german.

Comment 4

[leger]

Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.

Comment 5

[german]

I need to move this to m9. Won't get to it before then
Also,there is no dependency to bug 8640 as listed here, since that bug 8640
deals with the splitter widget, which has nothing to with the progress bar.

Comment 6

[german]

as soon as the tree will go green I will put in this change:
progressmeter{
        display:inline;
        border: 1px inset white;
        color : #9999CC;
        background-color: grey;
}

progressmeter[align="horizontal"]{
        height: 1em;
}

that way vertical variations will work, and the common horizontal case should
display nicely inline with the font being chosen (height 1em)

Comment 7

[german]

these changes are now checked in as of this morning. Feel free to re-open if
there's a problem.

Comment 8

[german]

these changes are now checked in as of this morning. Feel free to re-open if
there's a problem.

Comment 9

[gerardok]

QA Contact massive update.

Comment 10

[ckritzer (gone)]

This appears broken again.  I see what appears to be two vertical black bars,
the second slightly chopped...

Happens on:
- Linux6 2000-03-01-13 Commercial build
- MacOS9 2000-03-01-13 Commercial build
- Win98 2000-03-01-16 Commercial build

Comment 11

[ckritzer (gone)]

Dang, I forgot to reopen this earlier...

Also happens on:
- Linux6 2000-03-07-09 Commercial build
- MacOS9 2000-03-07-08 Commercial build
- Win98 2000-03-07-09 Commercial build

Comment 12

[Jim Roskind]

German,
Please update the TFV from M9, or dispose of this bug.
Thanks

Comment 13

[german]

since progress meter is now box/xbl based it is no longer limited by the widget
default, now it can be set to anything by a xul designer. marking fixed

Comment 14

[ckritzer (gone)]

Re-opening bug.

Now nothing is being displayed on the screen.

For builds:
- MacOS9 2000-05-02-08-M15 Commercial
- Linux6 2000-05-02-08-M15 Commercial
- Win98  2000-05-02-08-M15 Commercial

Comment 15

[shuang (gone)]

Move to later polish time. M20.

Comment 16

[german]

This was fixed a long time ago right? Kathy, I assume we can close this bug since 
Eric's rewrite of progress meter has been completed?

Comment 17

[bsharma]

Updating QA contact.

Comment 18

[german]

I am closing this bug assuming this was fixed with modern 2 redesign

Comment 19

[jerone]

verifried build 2001081303 & 2001081308 os:win95,linux7.1,mac8.6