Closed Bug 138764 Opened 23 years ago Closed 22 years ago

"Program description" in file properties is "|"

Categories

(SeaMonkey :: Build Config, defect, P3)

x86
Windows 98

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.2alpha

People

(Reporter: Junk_HbJ, Assigned: asasaki)

References

Details

(Whiteboard: has patch, needs review.)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv 0.9.9+) Netscape6/6.2.2 BuildID: 2002041711 If you right-click on "mozilla.exe" of RC1, the program description is a simple |. It's just a small glitch, but should be fixed for 1.0. I assigned this to build config, because such information tend to be inserted at building time and are normally part of some config scripts. Reproducible: Always Steps to Reproduce: 1. Check "File properties" of RC1 "mozilla.exe"
tri + [rfe] ? *evilgrin*
Over to XP Apps.
Assignee: seawood → sgehani
Status: UNCONFIRMED → NEW
Component: Build Config → XP Apps
Ever confirmed: true
QA Contact: granrose → paw
Back to Build Config.
Assignee: sgehani → seawood
Component: XP Apps → Build Config
QA Contact: paw → granrose
-> asasaki
Assignee: seawood → asasaki
wfm 2002042508 branch... guessing this has been fixed by my version.inc patch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 145705 has been marked as a duplicate of this bug. ***
I don't have a new branch build to check, but RC2 (on win2k) is newer than the build referred to in comment 5, and the program description still doesn't say anything. If I've duped bug 145705 correctly, then I'd say it's not "trivial" - it's not just people looking at the file properties, it actually affects configuration for Norton Firewall users too. Reopening. (hope I'm correct here!)
Severity: trivial → normal
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
oh, waitaminit, you're using linux. this isn't me. can take a look though.
no, no. well the reporter on this bug appears to have made the report with a linux build. however, they refer to "mozilla.exe" and "file properties", so it's definitely about Windows. certainly I'm referring to Windows, and so is the duplicate.
Michael, you're right :) I filed this bug with my Linux box at home, while I'm using Windows at work (I'm forced to do so. Argh!) where I saw this behavior.
Severity: normal → minor
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1beta
*** Bug 140803 has been marked as a duplicate of this bug. ***
All reports I've seen of this being a problem so far seem to be about windows 98, Junk_HbJ, can you confirm that you use win 98 at work? Or can anyone confirm this who isn't using windows 98? As was said in comment 7 and the just duped bug, this affects Norton Firewall, basically making using that firewall useless if you're also running Mozilla, as it is set wide open upon the creation of a rule for Mozilla.
I'm now just working on a NT 4.0/SP6a (heterogeneous networks are funny :), where mozilla.exe has no program description (field is just empty) and shows a funny behavior: After launching the the latest 1.0.0 build (from \latest-1.0.0, ID 2002060306) you can configure MS-DOS Application settings like "screen" or "fast pasting" after right-clicking on mozilla.exe.
as I said in comment 7, i can confirm this is the case in windows 2000, so I think we're talking about all (32-bit) versions of Windows. it is, after all, some info stored in the .exe file which windows looks at, so it makes sense for it not to show up in any version of windows if it's not there.
Using Windows 2000, when I tried to right click the mozilla.exe file and read the description inside the properties, it says "mozilla". So it seems to be ok in this OS/computer. But I confirm the Norton disaster using Windows 98 (as in bug 140803). Also, I know this is not to be used to report Netscape bugs, but Preview 7 has the same problem (and 6.2.3 works fine).
*** Bug 149564 has been marked as a duplicate of this bug. ***
It seems this bug has been fixed in Mozilla 1.0 alpha. Can everyone confirm this? Martijn
still not there for me. the problem here, AIUI, is that there is no version info in the .exe file, including no description. it seems the "description" on the "general" tab of the properties comes from different places according to windows version and what windows can find to fill in. for the problems mentioned in the dupes (Norton firewall and the "open with..." dialog) to be fixed, the version info needs to be present, and give a description (if the version info is there, the properties dialog will offer a "version" tab) adjusting the summary to make it clearer what is needed here. hope I understand correctly.
Summary: "Program description" in file properties is "|" → mozilla.exe has no version info (no program description in file properties)
On my Win98SE machine with Mozilla 1.1. Alpha: Now AtGuard 2.09 can handle the "Mozilla.exe" as it used to be! Thanks developers!! Thomas
ok, looks like the fix for the description is: 1) make sure BUILD_OFFICIAL is set (already done in verification builds) 2) make sure mozilla/config/milestone.txt is a milestone build (no + at the end) 3) add mozilla/xpfe/bootstrap/module.ver which is one line: WIN32_MODULE_DESCRIPTION = Mozilla and the description is set. I suppose comment 19 shows that these two things are unrelated? Or that you need to have a milestone build to use behind a Norton firewall?
oh dear - I think I have been thinking about the wrong things when I changed the summary and in my previous comments. Sorry :( restoring summary to what it said before I changed it. looking at the reports here and in the dupes, I see the Norton problem is reported with 0.9.9+, and RC2 and RC3, but apparently works in 1.1a. apologies for adding to the confusion - I'm still not sure what's going on here. and maybe what I was thinking of (full version info in the exe file) should be a separate bug, although it's minor?
Summary: mozilla.exe has no version info (no program description in file properties) → "Program description" in file properties is "|"
This is all that needs to be done: Index: xpfe/bootstrap/module.ver =================================================================== RCS file: xpfe/bootstrap/module.ver diff -N xpfe/bootstrap/module.ver --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ xpfe/bootstrap/module.ver 18 Jun 2002 21:42:53 -0000 @@ -0,0 +1 @@ +WIN32_MODULE_DESCRIPTION=Mozilla on branch. The reason comment 19 is true is that the versioning never landed for mozilla.exe on the trunk (where 1.1a was released from)... working on that, but I'll add module.ver to that patch when I check that in.
Whiteboard: has patch, needs review.
Target Milestone: mozilla1.1beta → mozilla1.2alpha
checked into the trunk with the fix for 136673
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Back with 1.0.1. This breaks AtGuard 3.22, because it _needs_ an application description and therefore can't create a correct rule for Mozilla. The created rule applies to all applications and renders Atguard useless.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
marking fixed again - the FIXED refers to the trunk - if you get 1.1 or 1.2alpha, this will be fixed. if someone thinks this is important enough to go into 1.0.2, that could happen...
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
this was never fixed on the branch. opening bug 168978.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.