If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[RFE] XPI should support context-based diffs

VERIFIED WONTFIX

Status

Core Graveyard
Installer: XPInstall Engine
P3
enhancement
VERIFIED WONTFIX
17 years ago
2 years ago

People

(Reporter: Rann Bar-On, Assigned: dveditz)

Tracking

({helpwanted})

Trunk
Future
x86
All
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
I should be able to write an XPI installer script that will search for a certain
string in a (usually text) file and insert/replace data in that file, based on
the location of that string.  For example, I may search for startup() in
navigator.js and insert a call to a function I want to run in another JS file
which I would have to insert a line to import, etc.  This would be very
important to people writing add-on packages to customise Mozilla.
(Assignee)

Comment 1

17 years ago
Interesting idea. Maybe we can incorporate Larry Wall's patch code, 'cause I'd 
hate to duplicate it. Would there be licensing issues?

Text patching XUL files will probably not turn out to be very useful, because 
chrome is going to be packaged into zip archives soon -- so then you'd need a 
tool that unzipped, patched, and rezipped. Oy! Maybe the current binary 
patching would be good enough, but it's fragile in the face of version 
differences.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Reporter)

Comment 2

17 years ago
wow...zip files?  I thought it was going to be jar.  And anyway, extracting a
single file from a zip, patching and putting it back shouldn't really be that
time consuming, considering these files would be read/extracted when moz uses
them anyway.  I think it will turn out to be useful for companies who want to
overlay the menu structure and/or modify it, as Mozilla is _suppposed_ to be
easily customisable.  If we don't provide the tools for such relatively-simple
customisation, we can promptly stop claiming big things as regards the
customisability of Mozilla.  Just having XUL there doesn't help if there are no
tools built-in to modify it with relative ease.
(Assignee)

Comment 3

17 years ago
I have no idea why people are calling it ".jar". A .jar file is simply a .zip 
archive with a different extension and some signing meta-data. Our chrome 
archives are not going to be signed and will not contain the extra meta-data so 
IMHO giving them a .jar extension is plain wrong.

If chrome *were* signed this technique would fail horribly as modifying a file 
would break the signature. You'd end up having to do a binary patch of the 
entire archive: you'd have to update the signature files when you touched the 
signed chrome files.
(Reporter)

Comment 4

17 years ago
ok, cool.  If we're not going to have signed files, then this should be 
relatively easy.  I hope it will be taken off 'Future'.
(Assignee)

Comment 5

17 years ago
"Future" just means I personally will not be able to deal with it in the 
foreseeable future, i.e. while swamped shipping Netscape 6.0.  IMHO this is the 
appropriate classification for a feature request at this point. In a future 
version, or if you can find someone else to do the work...
(Reporter)

Comment 6

17 years ago
well, can we put helpwanted on this then?  You were saying something about Larry
Wall's code?  If you give me more details, I could find out about that.  I would
do it, but my c++ knowledge is next to nothing :(.
Adding helpwanted keyword. Given that Moz will contain code for dealing with 
.zips/.jars, we should be able to use that. I don't think we can use Larry's 
patch code, as it seems to be under the GPL (at least, he hasn't maintained it 
for ages, and GNU now are maintaining it). We could try and find a pre-GNU 
version, but I doubt it would be much good comparatively.

Will Mozilla's new dual license permit the incorporation of pure GPL code, or 
not?

Gerv
Keywords: helpwanted
(Assignee)

Comment 8

17 years ago
Mozilla currently contains code to *read* zip archives, but not create them. 
Other people have requested it so creating archives may be generally useful 
(although others complain about feature bloat).

mozilla.org has no plans to accept GPL-only code.
(Reporter)

Comment 9

17 years ago
nominating nsbeta3, because (for the reasons discussed above), I think this
could turn out to be very useful.
Keywords: nsbeta3
(Assignee)

Comment 10

17 years ago
Unfortunately nsbeta3-: this is not the time to be adding new features. At 
least not Netscape employees; this could make a fine project for someone who's 
interested.
Whiteboard: [nsbeta3-]

Comment 11

17 years ago
This should not be allowed IMO on Mozilla XUL.  Overlays are going to be 
enhanced to do all of the things a patch might need to do, and altering the 
original XUL prevents the user from reverting changes and restoring defaults.

IMO this is a dangerously bad idea.
Closing as WONTFIX; use overlays instead.

Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Updated

17 years ago
Keywords: nsbeta3
Whiteboard: [nsbeta3-]

Comment 13

17 years ago
Marking Verified.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.