Don't include <wingdi.h> twice

VERIFIED FIXED in mozilla1.4beta

Status

--
trivial
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: d_king, Assigned: d_king)

Tracking

({memory-footprint})

Trunk
mozilla1.4beta
x86
Windows XP
memory-footprint

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030203
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030203

In nsTridentPreferencesWin.cpp there is an include of <windows.h> and one for
<wingdi.h>. However, <windows.h> includes <wingdi.h> itself, so we end up with
<wingdi.h> included twice.

Reproducible: Always

Steps to Reproduce:
(Assignee)

Comment 1

16 years ago
The fix is really simple, and I'm testing it now.....taking.
Assignee: racham → dgk
(Assignee)

Comment 2

16 years ago
Created attachment 114041 [details] [diff] [review]
Remove dup <wingdi.h>
(Assignee)

Updated

16 years ago
Attachment #114041 - Flags: review?(racham)
(Assignee)

Updated

16 years ago
Attachment #114041 - Flags: review?(racham) → review?(gbush)
(Assignee)

Updated

16 years ago
Attachment #114041 - Flags: review?(gbush) → review?(sspitzer)
Comment on attachment 114041 [details] [diff] [review]
Remove dup <wingdi.h>

the owner of this code is danm.
Attachment #114041 - Flags: review?(sspitzer) → review?(danm)

Comment 4

16 years ago
Comment on attachment 114041 [details] [diff] [review]
Remove dup <wingdi.h>

wingdi.h is for EnumFontFamiliesEx() but windows.h is the correct #include for
that. r=danm.

danm disavows all other knowledge of this code.
Attachment #114041 - Flags: review?(danm) → review+
(Assignee)

Updated

16 years ago
Attachment #114041 - Flags: superreview?(ccarlen)
Comment on attachment 114041 [details] [diff] [review]
Remove dup <wingdi.h>

since you got r=danm, rs=sspitzer

no need to waste ccarlen's cycles on this.
Attachment #114041 - Flags: superreview?(ccarlen) → superreview+
(Assignee)

Comment 6

16 years ago
Update: as I don't have CVS checkin privs, I've asked sspitzer to check this in
when he has time and the tree is open.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.4alpha
(Assignee)

Comment 7

16 years ago
Changing milestone as there is no way this could be considered critical for 1.4a
and bothering "drivers" with it.
Keywords: footprint
Target Milestone: mozilla1.4alpha → mozilla1.4beta
(Assignee)

Updated

16 years ago
Flags: blocking1.4b?

Comment 8

16 years ago
Checked in. Thanks David!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

16 years ago
Verifying via lxr and bonsai and lack of redness caused by this checkin. A minor
bug for sure, but it had to be done.

Found some interesting discrepencies. For example :-
http://lxr.mozilla.org/mozilla/source/extensions/tridentprofile/src/nsTridentPreferencesWin.cpp
&
http://lxr.mozilla.org/seamonkey/source/extensions/tridentprofile/src/nsTridentPreferencesWin.cpp

are different, with the seamonkey version having the change, but the other one
doesn't. I assume I'm just getting confused as I dig further into Mozilla, so I
wont file a bug unless someone suggests I should.
Status: RESOLVED → VERIFIED
Flags: blocking1.4b?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.