306599 - Software Update Progress Meter looks different (worse) than the one for Firefox

Status: VERIFIED WORKSFORME

(Thunderbird :: General, defect)

Description

[Peter Lairo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050830 Firefox/1.6a1
Build Identifier: version 1.6a1 (20050829)

The "Software Update" progress meter looks different (worse) than the one for
Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050830 Firefox/1.6a1)

Reproducible: Always

Steps to Reproduce:
1. In Thunderbird, select Help > Check for Updates (make sure there is one)
2. Accept download and let download, allow to restart to install
3. Observe the "Thunderbird is installing your updates and..." dialog's progress
meter.
4. Do steps 1-3 for Firefox *trunk* nightly (Deer Park Alpha 2)
Actual Results:  
- Thunderbird's progress meter' bar is blue and flat.
- Firefox's progress meter' bar is green and has a 3D-ish effect.

see screeshot for details!

Expected Results:  
The progressmeters should be the same, preferably like the firefox one.

PS. Notice my desktop wallpaper in the screenshot. ;-)

Comment 1

[Peter Lairo]

Attachment: Screenshot showing the different (inconsistent) progress meters

Comment 2

[Adam Guthrie]

I'm tempted to dupe this as bug 299745, but I really don't think it's the same
issue. I don't see why the native XP look wouldn't apply here...

Comment 3

[Peter Lairo]

That's Firefox (and fixed), this is a Thunderbird bug. ;-)

Could you then please CONFIRM this bug?

Comment 4

[Adam Guthrie]

This is /not/ a blocker...

Comment 5

[Simon Bünzli]

The issue is that for Thunderbird's updater, the manifest file required for enabling Luna-type styling is badly included. It should be index 1 of resource "24" but instead is index 1 of resource "RT_MANIFEST" (which is the name of the preprocessor macro which should be replaced by "24" during the build process).

Since this doesn't happen for Firefox and since both updaters are built from the same sources, the issue must lie with the specific build system/configuration itself.

Scott: Who's responsible for the Thunderbird build configuration?

Comment 6

[Scott MacGregor]

(In reply to comment #5)
> The issue is that for Thunderbird's updater, the manifest file required for
> enabling Luna-type styling is badly included. It should be index 1 of resource
> "24" but instead is index 1 of resource "RT_MANIFEST" (which is the name of the
> preprocessor macro which should be replaced by "24" during the build process).
> 
> Since this doesn't happen for Firefox and since both updaters are built from
> the same sources, the issue must lie with the specific build
> system/configuration itself.
> 
> Scott: Who's responsible for the Thunderbird build configuration?
> 

Simon, thanks for the insightful comments. I can't see anywhere in the tree where we define RT_MANIFEST as having a value of "24" anywhere on lxr for fx and tb. So I'm not sure where it gets defined for the Firefox updater. I'll cc some of the build team in case they know. Maybe there's a build flag that does this for fx.

Comment 7

[(not currently active) Ted Mielczarek]

We don't have the common controls manifest embedded on trunk.


*** This bug has been marked as a duplicate of 330231 ***

Comment 8

[(not currently active) Ted Mielczarek]

Actually that could have been overzealous.  This is on trunk, right?  And you're saying it's different between Firefox and Thunderbird?

Comment 9

[Simon Bünzli]

This isn't about the application itself but about the updater which does have the manifest included for both Firefox and Thunderbird - except that for Thunderbird the inclusion is faulty.

Comment 10

[(not currently active) Ted Mielczarek]

This is strange.  Firefox 1.5's updater.exe shows the same problem, but the 2.0b2's does not.  I'm going to build a thunderbird and see what it looks like.

Comment 11

[(not currently active) Ted Mielczarek]

Quick braindump before I go out:

Visual Studio 6.0 doesn't have RT_MANFIEST defined anywhere in the header files.  I assume the tinderboxen have a newer platform SDK installed, and that's how this works at all on Firefox.  The one difference that stands out between FF and TB's about:buildconfig is the --with-windows-version=400 in TB.  In the Platform SDK on my system I don't see RT_MANIFEST #ifdef'ed with that, so that might not make a difference.  If I had to guess right now, I'd say that the Thunderbird tinderbox has an old Platform SDK.  A trivial fix for this would just be to do:

#ifndef RT_MANIFEST
#define RT_MANIFEST 24
#endif

in updater.rc.

Comment 12

[(not currently active) Ted Mielczarek]

I do believe this is a tinderbox config issue, since my self built thunderbird has the manifest embedded properly.

Comment 13

[Scott MacGregor]

Ted, I'm still trying to understand why the 1.8 branch builds look differently between Thunderbird and Firefox. --with-windows-version isn't set on the branch tinderbox machines for either build:

Thunderbird: http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1174429080.1174433213.3007.gz&fulltext=1
Firefox: http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1174432920.1174435020.8940.gz&fulltext=1

the only difference in the configurations I see so far is Firefox uses MOZ_MAKE_FLAGS=-j4, thunderbird uses MOZ_MAKE_FLAGS=-j1

Oh here's another difference that looks suspicious on the branch machines:

Thunderbird:
-DOSTYPE=\"WINNT5.0\"

Firefox:
-DOSTYPE=\"WINNT5.2\"

I wonder if that could be it.

Comment 14

[Scott MacGregor]

I installed a nightly 1.8.0 build and updated it to another 1.8.0 build and it still has the progress bar problem. That build machine is WINNT5.2 so that must not be the culprit.

FYI, on the trunk this problem is WFM now. The problem is only on the 1.8.0 branch and the 1.8 branch. I'll keep looking through the build log between the Fx and Tb 1.8 branch nightly builds looking for differences in their configurations.

Comment 15

[(not currently active) Ted Mielczarek]

Scott: I will have to do some more research to recover my train of thought from those previous comments, but this could definitely be a compiler/SDK issue.  Since the branch builds are built with VC6, if they're not using an updated Platform SDK, they might be missing that define.  The trunk is built with VC8, so it doesn't have that problem.  You should be able to put in the workaround in comment 11 to get around this.

Comment 16

[(not currently active) Ted Mielczarek]

gavin pointed me at bug 336337, which I had forgotten about.  patrocles is using an old SDK, and trunk builds were moved off of it.  I think putting in the workaround is the path of least resistance here.

Comment 18

[raoul bhatia]

i do not exactly understand the issue, but i made screenshots of the updating 
process and hope that this will tell you what you want to know :)

cheers,
raoul

Comment 19

[raoul bhatia]

woops, this should go to bug 374662

Comment 20

[(not currently active) Ted Mielczarek]

Is this still an issue with Thunderbird 2.0.0.x? I suspect the build machines may have changed along the way.

Comment 21

[Simon Bünzli]

The manifest is still incorrectly included in Thunderbird 2.0.0.19's updater. The issue seems to have been corrected for Thunderbird 3 Beta 1, though.

Comment 22

[(not currently active) Ted Mielczarek]

Thunderbird 3 is building using VC2005 and an updated SDK, so it's probably strictly a VC6+SDK issue.

Comment 23

[Wayne Mery (:wsmwk)]

Peter, do you stll see this?

Comment 24

[Peter Lairo]

I can't get Thunderbird (daily) to show the update progress meter. Since so much time has passed, the update UI has been changed, and I'm now on Windows 7, I have to assume that this bug is no longer an issue. --> WFM

Comment 25

[Wayne Mery (:wsmwk)]

(In reply to Peter Lairo from comment #24)
> I can't get Thunderbird (daily) to show the update progress meter. Since so
> much time has passed, the update UI has been changed, and I'm now on Windows
> 7, I have to assume that this bug is no longer an issue. --> WFM

thanks Peter. please make it so - please change the bug's status and resolution settings