266459 - Progressmeter undetermined does not work on above URL

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Ian Neal]

Using BuildID 2004102407 on WinXP SP2
Steps to reproduce
1. Go to above URL
2. Look at progress meter

Expected result
1. Progress bar oscilates

Actual result.
1. No progress bar oscilating

Reasoning (I think)
Moving the progressmeter-undetermined css stuff from global.css to
progressmeter.css has caused this problem, see version 1.1.2.3
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/toolkit/themes/qute/global/progressmeter.css&rev=AVIARY_1_0_20040515_BRANCH

Comment 1

[Ian Neal]

This is on aviary branch, works fine on trunk

Comment 2

[Ian Neal]

Attachment: DOM Inspector of branch progressmeter

Comment 3

[Ian Neal]

Attachment: DOM Inspector of trunk progressmeter

Notice that the trunk is an xul:stack containing one xul:spacer whereas the
branch has no xul:stack and two xul:spacers

Comment 4

[Ian Neal]

I'll see if applying
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=progressmeter.xml&branch=&root=/cvsroot&subdir=mozilla/xpfe/global/resources/content/bindings&command=DIFF_FRAMESET&rev1=1.11&rev2=1.12
to the branch fixes the problem

Comment 5

[Ian Neal]

Reversing the checkin on 2004-08-16 11:29 to the branch fixes the problem, the
checkin comment was:
More improvements for Thunderbird's undetermined progressmeter. Move the xbl
binding out of content and into a theme css file. This keeps OSX and 3rd party
themes that have their own undetermined progressmeter stuff working.

Comment 6

[Ian Neal]

Putting the following back in xul.css fixes the problem:
progressmeter[mode="undetermined"] {
  -moz-binding:
url("chrome://global/content/bindings/progressmeter.xml#progressmeter-undetermined");
}

I guess this is something to do with the order the various style sheets are seen.
On trunk it is:
* from xul.css
progressmeter from xul.css
progressmeter[mode=undetermined] from xul.css
progressmeter from progressmeter.css
.progressmeter-statusbar from progressmeter.css

On branch it is:
* from xul.css
progressmeter from xul.css
progressmeter from progressmeter.css
.progressmeter-statusbar from progressmeter.css
progressmeter[mode=undetermined] from progressmeter.css

Comment 7

[Ian Neal]

This has now made it onto the trunk

Comment 8

[Gary van der Merwe]

Please see Bug 226491 Comment 41

Comment 9

[Gary van der Merwe]

Attachment: Testcase

Move binding from progressmeter.css to global.css

Comment 10

[Gary van der Merwe]

Attachment: Patch v0.1

oops - I uploaded my testcase rather than my patch

Comment 11

[Ian Neal]

Comment on attachment 176939 [details] [diff] [review]
Patch v0.1

Don't forget qute as well and all you are doing is reversing the checkin made
2004-08-16 11:29 see comment 5 for details.

Comment 12

[Gary van der Merwe]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=&filetype=match&who=scott%25scott-macgregor.org&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-16+11%3A29&maxdate=2004-08-16+11%3A29&cvsroot=%2Fcvsroot

Scott moved the binding from 
"mozilla/toolkit/content/xul.css"
to
"mozilla/toolkit/themes/winstripe/global/progressmeter.css"

and I'm moving it to 
"mozilla/toolkit/themes/winstripe/global/global.css"

Hence, the binding is found in the theme files, which means that it meet the
requirements of his original change.

Comment 13

[Ian Neal]

Sorry, I mis-read the patch, but my first point still stands - you also need to
do it for the qute theme don't you?

Comment 14

[Gary van der Merwe]

Attachment: Patch v0.2

Now with changes to qute theme too.

P.S. Where dose 'qute' get used?

Comment 15

[Asaf Romano (gone)]

(In reply to comment #14)
 
> P.S. Where dose 'qute' get used?

Thunderbird

Comment 16

[[e-mail]]

Comment on attachment 176958 [details] [diff] [review]
Patch v0.2

sr isn't required for toolkit, right?

Comment 17

[Gary van der Merwe]

Oh - I did not know that. How do I get this checked in? I don't have cvs access.

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 176958 [details] [diff] [review]
Patch v0.2

a=asa

Comment 19

[[e-mail]]

(In reply to comment #17)
>How do I get this checked in? I don't have cvs access.
Now that you have approval, Ian Neal might do it for you if you ask him nicely.

Comment 20

[Ian Neal]

Attachment: Patch that was checked in

Checking in qute/global/global.css;
/cvsroot/mozilla/toolkit/themes/qute/global/global.css,v  <--  global.css
new revision: 1.5; previous revision: 1.4
done
Checking in qute/global/progressmeter.css;
/cvsroot/mozilla/toolkit/themes/qute/global/progressmeter.css,v  <-- 
progressmeter.css
new revision: 1.6; previous revision: 1.5
done
Checking in winstripe/global/global.css;
/cvsroot/mozilla/toolkit/themes/winstripe/global/global.css,v  <--  global.css
new revision: 1.7; previous revision: 1.6
done
Checking in winstripe/global/progressmeter.css;
/cvsroot/mozilla/toolkit/themes/winstripe/global/progressmeter.css,v  <-- 
progressmeter.css
new revision: 1.6; previous revision: 1.5
done

Comment 21

[Gary van der Merwe]

Tested on Beast Build. ->Fixed

Comment 22

[Brian King [:kinger]]

The following testcases work for me in Firefox 1.0.4:
https://bugzilla.mozilla.org/attachment.cgi?id=176938
http://neil.rashbrook.org/pyeximon.xul

However, I have an extension that has a progress dialog. I put a simple
undetermined progress meter in there, and it doesn't work. The line does not
move. Code is just:

<hbox>
  <label id="pbarLabel" value="&progressprogress.label;"/>
  <progressmeter mode="undetermined"/>
</hbox>

Tried also with a trunk build of Thunderbird, but no go.

I'm pulling global.css into the window using it.

Any ideas?

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

Testcase: http://neil.rashbrook.org/pyeximon.xul

Verified FIXED using trunk build of SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060104 Mozilla/1.0

Comment 24

[Gary van der Merwe]

Note: my patch did not correctly fix Linux builds. This was fixed by Bug 315017.