Some .js files in jars are not stripped

RESOLVED WONTFIX

Status

()

Firefox
General
--
minor
RESOLVED WONTFIX
14 years ago
5 years ago

People

(Reporter: Radek 'sysKin' Czyz, Assigned: Waldo)

Tracking

unspecified
Firefox1.5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: 24th January 2005 trunk build

40 javascript files in all .jars have their license block in /* */ instead of #
symbols, and the license is not stripped when they're built.

I wish I could list them here, but I'm too lame to do that - they are just the
*.js files that contain "/* ***** BEGIN LICENSE BLOCK *****" text (as opposed to
"# ***** BEGIN LICENSE BLOCK *****")


Reproducible: Always

Steps to Reproduce:




I have no idea what would be the right component for that bug ;)
There's at least one in toolkit/content that I know.  This is mostly comm.jar
refugees, but we should fix these.
Assignee: firefox → mconnor
Status: UNCONFIRMED → NEW
Ever confirmed: true
this is about 40k of bits to strip, I'll fix these before 1.1
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox1.1

Comment 3

13 years ago
See also bug 68686.
(Assignee)

Comment 4

13 years ago
Created attachment 193495 [details] [diff] [review]
Patch for 10 of the files (in browser and toolkit only)

It looks like EXTRA_PP_COMPONENTS is exactly the same as EXTRA_COMPONENTS
except each component is preprocessed; if this is wrong I'll need to redo a
little bit of the patch.  I haven't built this, but I double-checked that I
covered all the relevant places to tweak to get all the changed files
preprocessed (when a file wasn't already preprocessed).
Assignee: mconnor → jwalden+bmo
Attachment #193495 - Flags: review?(mconnor)
These should probably use the new boilerplate suggested by bsmedberg, which have
the advantage of being (mostly) preprocessed out in addition to being valid JS
files.

http://gavinsharp.com/tmp/license-boilerplate.txt

Updated

13 years ago
Blocks: 171082

Comment 6

13 years ago
(In reply to comment #5)
> These should probably use the new boilerplate suggested by bsmedberg, which
> have
> the advantage of being (mostly) preprocessed out in addition to being valid JS
> files.
> 
> http://gavinsharp.com/tmp/license-boilerplate.txt
> 

That's a good idea, but I think it's wasted effort. Firstly, the files are left with:

/* ***** BEGIN LICENSE BLOCK *****
 * ***** END LICENSE BLOCK ***** */

which seems a bit strange.

Secondly, it doesn't necessarily mean the files are then valid script. You have to JavaScript comment every ifdef too:

/*
#ifdef
*/
  // code;
/*
#endif
*/

Even then, if it may be syntactically correct, it doesn't mean it's valid. You could have redeclaration errors and all sorts of problems. What's the need for valid pre-preprocessed files anyway?

My idea would be to have a boilerplate like the following (JS example):

# ***** BEGIN LICENSE BLOCK *****
# Version: MPL 1.1/GPL 2.0/LGPL 2.1
#
# [...]
#
# ***** END LICENSE BLOCK *****
/* The contents of this file are subject to the Mozilla Public License Version
 * 1.1 (the "License"). A copy of the License's terms is available in the file 
 * BOILERPLATE, located in the application directory.
 */

Then we could ship releases with only 1 copy of the boilerplate, yet every file is still under its terms (and hence the license). The referring text could be even shorter.

The boilerplate would then point to the license, as it already does.
(In reply to comment #6)
The fact that the files may not be otherwise valid doesn't excuse making them invalid, and there is no requirement to include the license header at the top of each file when it's shipped as an "executable" in a jar. See bug 68686.

Comment 8

13 years ago
That's true. So this (and bug 309418; dupe?) should be fixed by adding/replacing each file's boilerplate with one that gets preprocessed out, yet doesn't invalidate the file (at least, not more than it may already be) before preprocessing? That should be easy enough, but I think we have to wait for mitchell@mozilla.org (according to mconnor@mozilla.com in bug 279215) to approve (i.e. is it OK to not have the terms in each file, and if so, in how many places do the terms have to be? Top level, each directory etc.)

Why not have the comment delimiters outside the LICENSE BLOCK, rather than on the same line? That would reduce the size slightly more, and not leave an empty license block, but rather no block at all.

Updated

13 years ago
Attachment #193495 - Flags: review?(mconnor) → review+
(Assignee)

Comment 9

11 years ago
(Blast from the past!)

Patch checked in, with appropriate un-bitrotting tweaks (mostly for components which had already been switched to being preprocessed).  I didn't change the license format to a more JS-friendly format; someone else can do that if they care, but I don't see it as a huge issue.

There are still more files to change, so this bug remains open.

Comment 10

11 years ago
Created attachment 258907 [details] [diff] [review]
unbust SeaMonkey cookie dialog
Attachment #258907 - Flags: review?(neil)

Comment 11

11 years ago
Comment on attachment 258907 [details] [diff] [review]
unbust SeaMonkey cookie dialog

I still fail to understand toolkit's obsession with .jar size ...
Attachment #258907 - Flags: review?(neil) → review+

Comment 12

11 years ago
Comment on attachment 258907 [details] [diff] [review]
unbust SeaMonkey cookie dialog

(landed)
Attachment #258907 - Attachment is obsolete: true

Comment 13

11 years ago
footprint key word?
Per bug 309418, the new license headers are not large enough for this to matter.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.