18 years ago
13 years ago


(Reporter: doctor__j, Assigned: oeschger)


Firefox Tracking Flags

(Not tracked)



(3 attachments)



18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010622
BuildID:    2001062211

Coming to your local theatres NOW.

Reproducible: Always
Steps to Reproduce:
1. See the Premiere photo shoot!!

Comment 1

18 years ago
Created attachment 39845 [details]
Photo shoot #1

Comment 2

18 years ago
Created attachment 39846 [details]
Photo shoot #2

Comment 3

18 years ago
Help & Co. resurrected in bug 87315.
*** Bug 87696 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
Dang it if this bug isn't true! I checked in some updates on Friday that ought 
to have remedied this, but I verify that in the 2001062504 build, the help 
locale stuff is not being seen. All of the resources are placed correctly (i.e., 
the help chrome is in the help.jar and the localizable stuff--which includes the 
menu item, the table of contents, and the content itself--is in en-US.jar), but 
the entry is not being written correctly to the installed-chrome.txt file.

cc'ing ssu. Sean, what's not happening here? When I update the entry in the 
installed-chrome.txt file to point to the en-US.jar, everything is cool. But 
until I do this, that file is still looking in a subdirectory of help.jar.
this is a problem on linux too (build 2001-06-25-08)
OS: Windows 98 → All
Hardware: PC → All

Comment 7

18 years ago
Boris and DrJ: How did you come by these builds? Were they the nightlies you got 
from the mozilla splash page? 

I need to make sure that this is an issue with a recent installer version rather 
than a zip file (which might have something like an old installed-chrome.txt 
left over from before my updates late 6/21). I believe we verified that the help 
locale stuff was building and installing correctly after the packaging updates.

Thanks for getting back to me about this.
I'm using the build from the corresponding directory on the Mozilla ftp site. 
I'm also using the tarball (no installer), so a stale installed-chrome.txt could
well be the issue.

Comment 9

18 years ago
I'm getting all Moz builds from the ftp site too.
Too lazy/dumb to build one myself...

Comment 11

18 years ago
Ah, good spot Stephen. I spaced out on the makefiles (and updated only the up there). I will get this in as soon as I can. Thanks!

*** Bug 88009 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
Just checked in walk84's fix for this on the branch (but not yet on the trunk, 
where smoketests are still being done). Should see this problem resolved (but 
I'm going to wait a little bit before marking this fixed).

Also noting Asa and Leaf's suggestion that, in some cases, this has to do with 
the fact that the zips made available recently from didn't have the 
re-registered JARs. 

Comment 14

18 years ago

Comment 15

18 years ago
Coming in behind waterson to provide some context to his review here: I checked 
this fairly urgent into the branch yesterday (a=asa and, IIRC, rs=blizzard), but 
am going back and getting it reviewed in earnest. This same fix has to be 
applied on the commercial side (for which I have a patch posted in 5687), where 
I believe waterson has sr'd too.

As soon as the tree(s) open, I will do moz trunk, comm branch, comm trunk with 
this fix.

Comment 16

18 years ago
Checked in a fix for this today. Mozilla branch and trunk now package 
localizable stuff in en-US.jar (as opposed to help.jar) successfully. Marking 
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
Dude, there it is...

Confirming on build 2001-06-30-08, Win2kn sp2 from installer.

Comment 18

18 years ago
Um, clarification...

Confirming FIXED.  Sorry for the confusion!

Comment 19

17 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.