Closed Bug 50744 Opened 24 years ago Closed 24 years ago

JavaScript Console icon should be Netscape 6/Mozilla document type

Categories

(SeaMonkey :: Build Config, defect, P3)

PowerPC
Mac System 8.6
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: jj.enser)

Details

(Whiteboard: [rtm-] which package needs this file?)

saw this using 2000.08.29.08 mac commercial --asa, could you pls confirm if this
is also a problem on mozilla?

in the installation directory, the icon for JavaScript Console should be a
Netscape 6 (or Mozilla for moz bits) document type. right now it has "decode
document" as its filetype. if you double-click icon, you'll get a dialog asking
what application to use for opening it. selecting Netscape (or mozilla) works
and launches the js console --but you shouldn't get this dialog at all.
mac only. this is a regression since hadn't happened before.

over to jj --he's away...um, who could fix this in the interim? nominating for
beta3, in hopes that it can get fixed by then.
Assignee: cls → jj
Keywords: nsbeta3, pp, regression
I don't see an item for Javascript Console at all in Mozilla Installer build 082915.
!?

i wouldn't think that this would be a commercial-only feature. the js console
would be quite a useful tool...
we have the js console, just not an icon to launch it.  It can be launched from
mozilla Tasks|Tools menu item.
Sairuh,
This is very strange.  Neither the mozilla nor the commercial packages-mac 
manifests reflect this file.  In fact, I just installed the 3pm commercial build 
and can find no such file.  Are you sure someone didn't create this on your 
machine explicitly?
samir: that is odd. nope, it was definitely part of the 2000.08.29.08 opt
commercial build (i used the macbinary sea, not the installer). in fact, the js
console icon has been part of the build since i wrote the test plan for such
components, back in mid-july. i only recently noticed that the filetype has
differed.

should this icon not exist, then?
Sairuh,
If it's not part of the installed build we have no control over the file type 
and creator.  Hence, I would suggest this is a moot point.  Agree?

However, if someone deems the JavaScript Console the equivalent of an app (like 
Mail or AIM) and they simply forgot to update the packages-mac manifests (which 
would be the reason the icon doesn't get installed) then we can revisit this 
after it is added to the installed builds.
BTW, when I said "we have no control over..." I was referring to the installer 
folks.  I'm assuming we will not be distributing the .sea.bin archive for public 
consumption.
hm, i thought that we do distribute the sea.bin to the public --we certainly do
for the mozilla bits, at least.

i'm cc'ing phil (who works on js) and grace --are either familiar enough with
the js console icon? ie, if it should be part of the sea.bin or installer? would
either of you know which developer "maintains" the js console icon. fwiw,
Mozilla JavaScript Console is mentioned in NGLayoutBuildList.pm, line 2586.

(side note: i wouldn't consider this a hot issue. since the jsconsole icon does
launch the js console, after a bit of twiddling. if the filetype doesn't get
resolved for beta3, relnoting would be okay.)
we push the mac mozilla non-installer blob
(ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-08-30-08-M18/mozilla-mac-M18.sea.bin)
to mozilla.org along with the mac mozilla installer blob.

for netscape 6, we put the non-installer blob up on ftp.netscape.com for PR1 and
PR2 since the installer was not available, and broken, respectively.  Last I
heard, we had fixed the mac installer for PR2 and had pushed out the installer
and removed the links to the non-installer PR2 blob.

The plan that build release is working from is that we will only be shipping
installer bits come RTM.
Thanks for the clarification Jon!  So we need to worry about this for Mozilla 
but not for Netscape 6.
well, I wouldn't say we need to worry about it for mozilla either.

basically, we only need to worry about it if someone says this icon should be in
the installer builds.  If it's supposed to be in the installer builds and it
isn't that's a problem.  If it's just a handy thing someone put into :viewer:bin
that's getting picked up in the blob, then we can resolve this invalid.
ok folks, I'm back and can clarify with a few statements:

- any file added by the developers to the build system through the perl files 
located at mozilla/build/mac or ns/build/mac, and being exported to dist, will be 
found in the mozilla-mac.sea.bin or netscape-mac.sea.bin distribution. (this is 
the case for Mozilla JavaScript Console)
- if such files are ALSO listed in the appropriate packages-mac file, they will 
ALSO be packaged in the corresponding .xpi and will ship with the installer. 
(this is NOT the case for Mozilla Javascript Console)
- Specific changes (like file name, icon, type, or creator) must be made to the 
release build automation in order to show up in the installer. This didn't happen 
for Mozilla Javascript Console.

So, what do we do from here ?
If this file needs to be in the mozilla installer, I need to add it to mozilla/
xpinstall/packager/packages-mac and also make sure it gets the right file type 
and creator during packaging.
Now, I heard that we DON'T want this file to ship with Netscape 6. If this is 
true, then I'll have to REMOVE it from the browser.xpi since this guy is derived 
from the mozilla version.

I need a ruling on this to proceed.
Status: NEW → ASSIGNED
Keywords: nsbeta3, pp, regressionrtm
Whiteboard: [rtm need info] which package needs this file?
My two cents ... If a component could potentially be used by itself (e.g. 
Bookmarks, ahem!), it should have its own icon. If it is of no use by itself 
(e.g. JavaScript Console), it should not have its own icon.

However, you may want to consider the plight of XPToolkit app developers who are 
trying to develop apps which don't have a Tasks menu, let alone a JavaScript 
Console menu item, but who still want to see what sort of errors they're 
creating. Is the JavaScript Console useful for those people? If so, then it 
should be retained (and included in the installer), but chucked into the 
`Components' folder so that Joe User doesn't have to wonder what it does.

By the way, *all* the component shortcuts have had `decode document' filetypes 
for as long as I can remember. At the very least this should be `Mozilla 
document'.
This bug isn't really a pull it off the wire buts.  If we don't get this bug
moving so it's rtm+ by the end of the day it's not going to make rtm++.
no activity in a week.

rtm-
Whiteboard: [rtm need info] which package needs this file? → [rtm-] which package needs this file?
again, Javascript Console is currently NOT part of the Netscape 6 installer, 
hence rtm-. I even think the 'rtm' keyword could be removed altogether.

Matthew, regarding the "decode document" string, that means you have an app named 
"decode" somewhere which has the same creator as Mozilla (MOZZ). If you remove 
this app or change its creator code, the shortcut will fire up mozilla as 
expected.
No, there is no `decode' app on these computers, and the shortcuts do fire up 
Mozilla as expected. But Mac OS still refers to a Mozilla shortcut as a `decode 
document'. Is no-one else seeing this? Should I file a separate bug?
Looking at any of the mozilla shortcuts in the install directory (Mozilla
Profile Migration, Mozilla Preferences, MozillaEditor, any of them) command I
displays Info that says "Kind: decode document".  Also strange that the Install
Log is classified as decode document and Mozilla Preferences shortcut doesn't
have the "-URL (mozilla icon)" icon.
When we AppleSingle decode during installation we create a temporary file named
"decode" (or "decode-1", "decode-2", etc. if "decode" already exists).  Somehow
this is being left around.  We /do/ set the finder info so I'm not sure why the
original temp file name is being associated as the document "type".

Simon, any insight?
Most of these shortcuts have been removed now, so this is moot. But I don't know 
why things are showing up as 'decode' documents, unless the installer creates a 
temporary file called 'decode', with type 'APPL' and creator 'MOSS' or 'MOZZ'. Is 
this the case, samir?
type    = '????'
creator = 'MOZZ'

http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsAppleSingleDecoder.cpp#114

Should we change the creator to '????' too?
Marking fixed since this file is no longer part of the Netscape build.

If not done yet, a new bug should opened about the file type/creator assigned by 
the installer as well as the "leftover" "decode" document. (samir?)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Bug 59217 filed regarding the creator for the temp doc during AppleSingle decoding.
verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.