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)
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.
Reporter | ||
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
I don't see an item for Javascript Console at all in Mozilla Installer build 082915.
Reporter | ||
Comment 3•24 years ago
|
||
!? i wouldn't think that this would be a commercial-only feature. the js console would be quite a useful tool...
Comment 4•24 years ago
|
||
we have the js console, just not an icon to launch it. It can be launched from mozilla Tasks|Tools menu item.
Comment 5•24 years ago
|
||
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?
Reporter | ||
Comment 6•24 years ago
|
||
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?
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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.)
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
Thanks for the clarification Jon! So we need to worry about this for Mozilla but not for Netscape 6.
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
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
Whiteboard: [rtm need info] which package needs this file?
Comment 14•24 years ago
|
||
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'.
Comment 15•24 years ago
|
||
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++.
Comment 16•24 years ago
|
||
no activity in a week. rtm-
Whiteboard: [rtm need info] which package needs this file? → [rtm-] which package needs this file?
Assignee | ||
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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?
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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?
Comment 21•24 years ago
|
||
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?
Comment 22•24 years ago
|
||
type = '????' creator = 'MOZZ' http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsAppleSingleDecoder.cpp#114 Should we change the creator to '????' too?
Assignee | ||
Comment 23•24 years ago
|
||
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
Comment 24•24 years ago
|
||
Bug 59217 filed regarding the creator for the temp doc during AppleSingle decoding.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•