Closed Bug 100425 Opened 24 years ago Closed 24 years ago

Need to support display of license or readme files in Mac OS X

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: slogan, Assigned: jj.enser)

References

Details

(Whiteboard: [PDT+] [OSX+] [ETA 09.26])

Attachments

(5 files, 1 obsolete file)

patch file
5.64 KB, patch
Details | Diff | Splinter Review
EULA.rsrc.sit - contains resources used by ShowEULADialog().
346 bytes, application/octet-stream
Details
Take 2, add 'EULA' resource, read name of EULA.txt out of the dialog's title.
10.62 KB, patch
Details | Diff | Splinter Review
Stuffed "EULA.txt" into DLOG's title.
361 bytes, application/x-stuffit
Details
N6.2 EULA .txt file with paragraph breaks
17.08 KB, text/plain
Details
Over to simon to express how we do this. Simon, put what you know here and then assign back to me.
Keywords: nsbranch+
Whiteboard: PDT
Target Milestone: --- → mozilla0.9.5
This is how we decided to add support for showing a EULA in Mozilla: 1. Early during startup, we put up a native dialog that contains the EULA in a scrolling text box, and OK/Cancel buttons. 2. If the user hits the OK button, we write a resource to the Mozilla binary to indicate that the EULA was accepted. 3. Subsequent runs check that resource, and run without showing the EULA. I propose that the resource should be 'EULA' ID 0. In more detail, the process of showing the splash should be as follows: 1. Check for EULA 0, if it exists, skip the following. 2. Read the name of the EULA file from a 'STR ' resource. 3. Attempt to locate the EULA file on disk; if it fails, bail. 4. Put up a native dialog with scrolling text box and OK/Cancel buttons 5. Read the EULA file into the scrolling text box (32k limit?) 6. Use ModalDialog event loop to wait for user confirm or cancel. 7. On user confirmation, create 'EULA' 0 resource as an empty resource, and continue. 8. Tear down the dialog. If the user canceled, ExitToShell(). Issues: * This adds native UI that might need localization. What should the dialog look like? Does it need any strings other than OK/Cancel buttons? * This adds code that runs at every startup, that imposes some (slight) risk. * The code needs to run on Mac OS X only.
OS: other → MacOS X
Hardware: PC → Macintosh
Over to syd for first cut at implementation
Assignee: sfraser → syd
QA Contact: bugzilla → ktrina
what if we can't write back to the app for some reason (it's on a CD or in a read-only application folder owned by root)? We should run in that configuration, or is that totally impossible these days anyway?
Status: NEW → ASSIGNED
1. For any text that may be needed to add to the dialog, I will cc: robinf in documentation. I wonder if we need text that says "If you do not accept the license, click Cancel." or something like that. Robin, do you know? 2. Does the license file have to be formatted in any special way for this dialog? We get the license file as text files, I think. Have to check. 3. If a user upgrades to a later Netscape/Mozilla version, will s/he still see the license file for the newer version? (assuming we still present the license in this manner). Thanks for the prompt work on this!
if we implement it the way we're planning, yes, they will see the license when they upgrade as it is tied to the application binary, not a profile. however, they will see the license again if they install another copy of emojo on the same machine and run that. i guess that's ok, just that no other apps do it that way.
Whiteboard: PDT → PDT [OSX+]
Need legal approval for this implementation.
Re: ------- Additional Comments From lchiang@netscape.com 2001-09-19 11:14 ------- >1. For any text that may be needed to add to the dialog, I will cc: robinf in >documentation. I wonder if we need text that says "If you do not accept the >license, click Cancel." or something like that. Robin, do you know? Instead of OK/Cancel, I think the button to accept should be labeled "Accept", and the button to decline should be labeled "No". We should include text that says "Click Accept if you accept the terms of the license agreement. If you click No, setup will quit." mlemley, can you please review? >2. Does the license file have to be formatted in any special way for this >dialog? We get the license file as text files, I think. Have to check. The text does need to be wrapped such that it fits in the dialog without requiring the user to horizontally scroll. mlemley supplies the EULA as a text file, which may need to get wrapped to fit in the Mac dialog. Please see bugscape bug 8853.
why not "Accept" and "Decline"? That would make sense. "No" doesn't make any sense to me.
You have legal approval for the implementation. Rather than OK/Cancel, there must be an "Accept" button. I also think "Decline" makes sense for the other button. There should be text in the dialogue box right above the buttons that explicitely states: Click "Accept" if you agree to the terms and conditions of the Agreement, otherwise click "Decline" and Setup will exit. If you let me know what the margins of the Mac dialogue box are, then I can set those in Word and save the Word file as "text with hard breaks" in order to provide a .txt file in proper line-wrapped format. Also, can someone let me know if there is a size limit (I saw "32K limit?") and whether the dialogue box for Mac can display an extended character set (e.g. french accent characters).
The Mac Toolbox code can handle the text wrap ok so that isn't a problem. Accented text is OK except I think the Mac and PC differ on some high-ASCII characters so you'll wnat to pre-flight it. Keeping the text length under 32K characters is definitely preferable but it can be worked around if necessary
well, the workaround for > 32K is to use WASTE, and we so don't want to go there. Let's make sure we keep it under 32K. Just to inject a little mozilla-ness into this bug (we are in bugzilla, afterall), what license will the mozilla version show? Is there one? Is this applicable to mozilla?
Syd - Status pls ...
Whiteboard: PDT [OSX+] → PDT [OSX+][ETA 09.25]
Attached patch patch file — — Splinter Review
this patch doesn't compile under carbon. many data structures are now opaque or non-existent. the patch also needs an extra newline at the end to apply.
since you never create the storage for your DocumentRecord, casting the windowptr to a DocumentPeek then dereferencing things off the end of it starts corrupting the heap. i'm pretty sure that's why it crashes. If you're going to piggy-back the data, you need to tell GetNewDialog where to create the structure so that space is allocated for your DocumentRecord.
Taking per macdev meeting decision.
Assignee: syd → beard
Status: ASSIGNED → NEW
Thanks for taking this Patrick, let me know if there is need to test build this on Mac OS 9 (I've got a tree, and can easily do this)
I'm just about ready to check in a fix for this. Patch coming.
Responding to Mike Lemly's question, yes the TextEdit code I am using allows you to display french or other european character sets. I am assuming that whatever localization is done will correspond to the Mac's system script. In addition, the display routines can support style information if you like. To make a localized EULA.txt file that contains sytle information (and is <32K), copy styled text from your favorite word processor into a new file using SimpleText, which will store the style information as a 'styl' resource.
Adding Montse to cc: list as beard's forthcoming comment is going to have I18N/ L10N implications
Some comments: What about the EULA resource? Don't we need that (or something) to determine if the file was already displayed on first launch? We don't want this to show each time. Just a reminder that sfraser suggested that we read the EUAL file name from a STR resource (instead of hardcoding it into a FSSpec definition). Patrick, thanks for all of this work.
What about having the .smi show the EULA?
Now that the coding is out of the way (for the most part), I tried a little experiment with the Disk Copy utility. It turns out that one can write an AppleScript that directs Disk Copy to convert a disk image (compressed or otherwise) into a "self mounting image" (.smi). Then, opening up one of Apple's .smi files, such as "Startup Disk 9.2.1.smi" with ResEdit, I discovered that it contains some extra resources that provide a way to display a license agreement before the disk image is mounted. Here's what I found: Type ID Name CNTL 5000 DITL 5000 Legal DITL dlgx 5000DLOG 5000 Legal DLOG infn 5000 LPic 5000 STR# 5001 German STR# 5002 English STR# 5003 Spanish STR# 5004 French STR# 5005 French STR# 5006 Italian STR# 5007 Japanese STR# 5008 Dutch STR# 5009 Swedishstyl 5001 German styl 5002 English styl 5003 Spanish styl 5004 French styl 5005 French styl 5006 Italian styl 5007 Japanese styl 5008 Dutch styl 5009 Swedish TEXT 5001 German TEXT 5002 English TEXT 5003 Spanish TEXT 5004 French TEXT 5005 French TEXT 5006 Italian TEXT 5007 Japanese TEXT 5008 Dutch TEXT 5009 Swedish If I copy all of these resources to a new .smi file that I construct, then my .smi file when launched will display the legal agreement dialog. The dialog contains a popup menu that includes all of the languages listed above, and the 'STR#' resources contain localized strings for all of the controls/buttons in the dialog. Finally, if one of these .smi files is launched under Mac OS X, the Classic support system doesn't get launched, instead the Mac OS X version of Disk Copy gets launched, and it shows the EULA dialog. I think we should strongly consider using this mechanism rather than adding some new code to present this dialog. The only downside to using this mechanism is that it is undocumented, and Apple could stop supporting it in the future. However, as an interim, low cost solution, that works on all released and soon to be released versions of Mac OS X, this is a pretty good solution. Comments?
Status: NEW → ASSIGNED
Syd, you're right, I haven't put in the code that adds the 'EULA' resource. Read my comments about .smi files and resources. I will add that code if we decide we don't want to go the .smi route.
Here's what I was trying to type before, but NS6.1 let me down: Resources that are required by the .smi: Type ID Name CNTL 5000 DITL 5000 Legal DITL dlgx 5000 DLOG 5000 Legal DLOG infn 5000 LPic 5000 STR# 5001 German STR# 5002 English STR# 5003 Spanish STR# 5004 French STR# 5005 French STR# 5006 Italian STR# 5007 Japanese STR# 5008 Dutch STR# 5009 Swedish styl 5001 German styl 5002 English styl 5003 Spanish styl 5004 French styl 5005 French styl 5006 Italian styl 5007 Japanese styl 5008 Dutch styl 5009 Swedish TEXT 5001 German TEXT 5002 English TEXT 5003 Spanish TEXT 5004 French TEXT 5005 French TEXT 5006 Italian TEXT 5007 Japanese TEXT 5008 Dutch TEXT 5009 Swedish
I urge everybody to look at Patrick's comments with the time stamp of 2001-09-25 18:21 and voice their opinion. I think adding the EULA to the disk image for display is a much cleaner/simpler solution than modifying the Mozilla/N6 app to do it.
Well, doing that (this diskimage hack) does lock us into having to install the bits that way. The original plan decouples us from the mechanism by which the bits get delivered, thus making it (how we install) more flexible to change.
Re: ------- Additional Comments From robinf@netscape.com 2001-09-19 16:24 ------- > > Re: ------- Additional Comments From lchiang@netscape.com 2001-09-19 11:14 ------- > >2. Does the license file have to be formatted in any special way for this > >dialog? We get the license file as text files, I think. Have to check. > > The text does need to be wrapped such that it fits in the dialog without > requiring the user to horizontally scroll. mlemley supplies the EULA as a text > file, which may need to get wrapped to fit in the Mac dialog. Please see > bugscape bug 8853. Actually, the EULA text will look better if each paragraph isn't wrapped. The text box I'm using does wrapping itself. This lets us modify the size of the box without having to rewrap the EULA text. Just put hard line breaks between paragraphs.
jumping in with my $.02, i think using DiskCopy to display the EULA is the right thing.
adding more i18n/l10n people; thanks for the heads up!
Passed 09.25, what's the new ETA?
syd, look at it this way: The disk image hack involves no code change. It only affects installs of the OS X version which is the only build we're currently planning to distribute in that format. It doesn't involve writing to the app's resource fork. I noticed on re-reading some of the OS X docs last night that that is frowned upon (primarily due to issues with having write access to the directory containing the app but that may change in the future). As I've said before, I think it's a much cleaner/simpler solution and both Simon and I would have suggested it but for thinking the .smi format wasn't OS X native. Kudos to Patrick for discovering it.
Adding jj, as he's most likely the one who will do the packaging. JJ, would you weigh in on with your opinion? Are there any Apple tech notes describing this feature (displaying a license agreement from a .smi)? We should ask somebody at Apple.
Keywords: patch
Whiteboard: PDT [OSX+][ETA 09.25] → PDT [OSX+][ETA 09.26]
Wow, lots fo reading here to catch up with :-/ So here are my comments/questions: 1. does adding the EULA dialog code to an .smi file serve the same purpose as having this code in NS ? IF we go for one (or the other), does this mean we don't need the second implementation ? 2. We were planning on packaging OSX into a .img file, not .smi since .smi will launch classic. Is that not a problem? 3. In the .smi scenario, can the EULA content come from a file on disk rather than a TEXT/styl resource? That will make release & localization work easier 4. wrapping & charset: That has already bitten us in the past. The license as it shipped with 6.1 is checked in as a hard-wrapped latin1 file and without any extended char so that it displays fine on all platforms. This is most likely what we'll use for OSX as well. 5. I will try to find out with Apple if the "EULA dialog on .smi mount" feature is documented somewhere, but I think we can proceed since Patrick figured it all out :-)
> ------- Additional Comments From jj@netscape.com 2001-09-26 12:55 ------- > > Wow, lots fo reading here to catch up with :-/ > So here are my comments/questions: > 1. does adding the EULA dialog code to an .smi file serve the same purpose as > having this code in NS ? IF we go for one (or the other), does this mean we > don't need the second implementation ? You got it. We don't need the code if we can stick the EULA into the disk image file (a .smi). > 2. We were planning on packaging OSX into a .img file, not .smi since .smi will > launch classic. Is that not a problem? No, it's not a problem, because Mac OS X special cases these applications, and launches the Mac OS X version of Disk Copy, which handles the dialog display itself. > 3. In the .smi scenario, can the EULA content come from a file on disk rather > than a TEXT/styl resource? That will make release & localization work easier I don't believe so, it must be in a resource. It's trivial to copy and paste these resources with Resorcerer et. al. > 4. wrapping & charset: That has already bitten us in the past. The license as > it shipped with 6.1 is checked in as a hard-wrapped latin1 file and without > any extended char so that it displays fine on all platforms. This is most > likely what we'll use for OSX as well. Hard wrapping is fine until it isn't. If the window is too narrow, or the font metrics differ on various systems, hard wrapped text becomes ragged and awful. I'd argue for using SimpleText formatting for this purpose (only put carriage returns at the end of paragraphs). I'm fine with sticking to ASCII/latin1.
we like it. let's get all the EULA translations, and make sure we have a URL to the japanese license agreement on site. JJ - Do you have everything you need to fix this bug? We think you are the owner of this one.
Whiteboard: PDT [OSX+][ETA 09.26] → PDT+ [OSX+][ETA 09.26]
Michele/Richard - We need translations of the EULA as soon as possible.
Reassigning to me. Release automation will grab the license from the usual location (mozilla/LICENSE for mozilla and ns/xpfe/global/resources/content/license.txt for netscape) and turn it into a TEXT resource as part of the packaging process. Patrick, I might need to work with you to get the proper additional resources you listed. For L10n, according to Patrick's earlier comment, appropriate STR# and TEXT resources will have to be added to the .smi files with localized UI strings and license text.
Assignee: beard → jj
Status: ASSIGNED → NEW
Who needs translations of the EULA asap? Don't those go into the localized product only. Currently we don't have plans to have the EULA ready until 10/8 since we know it always changes up until the last minute. Is the EULA final now?
The N6.2 Eula is finalized and was attached to bug 8853. Note that the file attached to 8853 is a .txt file with hard breaks on each line suitable for display by the Windows dialog box (which does not automatically wrap the text). The file for the Mac OS X build, from what I have read in this bug, should be the same text, but should be .txt with hard breaks only at paragraphs. I will attach the N6.2 license text with paragraph only breaks to this bug. The license text includes a line of French with accent characters toward the end of the file (which raised the question at one time as to whether it was a length of file problem or character set problem since the file loaded properly after the last portion was removed).
adding rchen
Msanz - Can you respond to Michele's question in this bug?
Whiteboard: PDT+ [OSX+][ETA 09.26] → [PDT+] [OSX+] [ETA 09.26]
I just sent her and Richard a message. I think it's nice to have all translations in the US package, but if that is not possible due to deadlines, then we should include US only in the US build and avoid dependencies. 10/8 is too late, so that means Japanese license cannot be in the US build. Richard, any update in European ones?
I'll check with our translation agency to see if we can get the ja EULA sooner than 10/8. But I won't know that until at least Monday 10/1. More info to follow then.
Concerning translations: The ONLY change to the EULA text from N6.1 to N6.2 is the version number. The substance of the text did not change. We should be able to put "6.2" in place of "6.1" for the translations that were previously used.
We have completed a diff between the 6.1 & 6.2 EULA's and can only find 2 minor changes. So, from a localisation standpoint, if we can confirm that there will be no changes to the EULA before RTM , then we just have to modify the version numbers.
packaging automation is ready to be updated with the "popup" license dialog. Test build has been delivered to internal ftp (currently displays the Netscape EULA). ftp://sweetlou.mcom.com/products/client/seamonkey/macos/10.x/ppc/2001-10-01-04-0.9.4/MozillaforMacOSX.smi.bin btw, how come Netscape 6.next EULA is posted as an attachment to this *bugzilla* bug? Oh, and speaking of that EULA, "Netscape 6.1" is still mentioned 4 times. I fixed this in my test build.
Status: NEW → ASSIGNED
Depends on: 100168
jj, it's probably not showing the icon because the plst isn't being found. for packages, it needs to be a stand-alone text file, not embedded in the app. this file currently lives in mozilla/xpfe/bootstrap/mozilla.plst (and netscape.plst in the ns tree) I forget where it has to live, but probably in the top-level of the package. Not sure why it doesn't run. I like the license agreement on the .smi. pretty slick.
according to "Inside MacOSX: System Overview" the bundle needs to have the file "Info.plst" (the mozilla.plst that is checked into the tree) in the Contents folder. So it should look like: - MyBundle - Mozilla (alias to Contents/MacOS/Mozilla) - Contents - PkgInfo - Info.plst - MacOS - Mozilla PkgInfo contains the type/creator codes of the app. It is redundant according to the docs, but is necessary for quick lookup by the finder (to avoid reparsing the plst every time).
adding the PkgInfo file (with the contents "APPLMOZZ") gave us an icon in the finder, but not the nice 128x128 one. I keep running into problems where the finder thinks the "Contents" folder is busy, so it's grayed out. I think that's why it won't pick up my plst. Not sure.
working on adding info.plist & PkgInfo files to the OSX package. A new packge will be delivered soon. Jaime, Sol, Since the license is now displayed every time the disk image is mounted, do we need to include the license agreeement as a text file next to the application ? (in comparison, for OS 9, the license file is next to the installer, but doesn't get installed with the product) So far, the only icons in the netscape folder are: - Netscape (application bundle) - Read me file - Profile Manager - Profile Migration
JJ: As long as the user must see and agree to the license upon installation of the product, and there is some path back to the license for future reference (e.g., go to "Help | About Netscape 6" and click on the "license" link), then I think we are OK. I'm not sure if that is what you are describing.
We will deliver the JA EULA to JJ by the end of today. We'll also attach a copy of it this bug then.
Sol: Thanks, you answered my question. User can definitely get to the license again the way you said (about page, license link), or every time the disk image will be mounted on the desktop. (just like it shows up every time the user launches the OS9 installer). So be it. No license file on disk. Michele: I got an email from Richard Close (Ireland) with FR, DE and ES licenses. (but no JA). Am I supposed to include all of these together with the English one inside the US-English disk image ?
JJ - yes as I understand it you're supposed to include all the localized license agreements from Ireland and from me (JA) in the US- English disk image. But maybe Sol or Montse can confirm this since I only heard it from them.
Montse: Do you know how we exposed localized licenses to users of 6.1? I do not.
I believe the localized licenses appeared in the localized releases only. I don't think they've ever been in the US build before... but I could be wrong... Montse - would know for sure.
they haven't been included in the US builds before. We thought it'd be nice to include them since the dialog supports multiple langs. Sol, what do you think, should we?
I'd prefer to follow the simplest path at this point. If it is simpler to only include the US-English license with US-English builds, let's do that. If it's simpler to include the localized licenses, let's do that. I do recall that we had problems at some point when the application was "choking" on the non-ASCII characters in the localized licenses. France requires a paragraph to be included in French in order to bind French people to the terms of the license, so we included the paragraph, but converted all non-ASCII characters (e with an accent) to ASCII. I just want to be sure we don't run into that issue if we attempt to display localized licenses to US-English users.
It's not more complicated to have some localized licensed added to the packaging process, as long as the list and content don't change too often :-) We'll have to put a process in place so that L10n people can freely check in changes to the localized license in the ns tree so that Release builds pick them up automatically, but right now the texts I already have will be stored on the OSX build machine in a resource file that only I can access & update. I received via email The EULA localized for FR, DE, ES and JA. As indicated above (2001-09-20 06:13), Each license should be < 32K. JA is currently 34K and should be reduced to fit that requirement. (one way top cut it in half is to remove the English license from the JA doc even though it has always contained both languages) I'll include what I can next time I repackage the OSX disk image. (probably tomorrow)
Have we tested that the EULA _has_ to be <32K for the disk image trick? I know ResEdit can't handle a TEXT resource >32K but I believe Resorcerer can.
It's not a ResEdit/Resorcerer limitation, it's a limitation of the TextEdit API, no?
who said it was an resource editor limitation ? It is a TextEdit limitation as Patrick said in his comment of [2001-09-25 15:14]. Patrick, any idea why Japanese is always greyed out in the language menu? (even with a non-empty TEXT/styl resource) ? I've ssen that during testing under 9, haven't tried under X yet.
You don't have a Japanese capable system. It's greyed out on OS 9 for me, but on OS X it works fine.
We don't know for sure the code that displays the license for disk images is TextEdit based under Mac OS X but I just checked and it durn sure is for Mac OS 9 (put more than 32K of text in that resource and you crash with a corrupted heap). Oh well, time for a shorter JA EULA
We currently have the problem Steve mentioned with JA and the workaround has been to ship the US one (legally binging anyway) and provide a link to a page for the translation as a courtesy. I'd recommend bundling the European ones
There's no way to shorten the JA EULA. It's a direct translation of the US EULA. I guess we'll have to leave the JA one out of the US build.
We always bundle English together with Japanese EULA because of the legal issue. But for OS X, since all languages will be available for users, I think we can remove English text from the Japanese EULA, for OS X only. Thus, the size will be way smaller.
Blocks: 102989
I agree with Ying-Lin about the redundancy of the English text since the user can switch on the fly to read the license in several languages. However, I tested the 34K JA license undex X and it doesn't crash and the entire text seems to be displayed. Only problem I see with my 10.0.4 system: the text is displayed as single byte. (no japanese glyphs)
Target Milestone: mozilla0.9.5 → mozilla0.9.6
whoa! we need this on the branch. this is a PDT+ and OSX+ bug. why are we moving it out to 096?
No worries, this will be in 6.2 regardless of the tfv. Current status is that I have a "tentative" automation that creates a disk image for OS X which pops up a dialog with the license agreement in English, German, French, Spanish or Japanese. Only problem so far is that the japanese text is displayed as garbage (header and buttons ARE displayed in japanese) fyi, today's NS6.2 for OS X deliverable is here: ftp://sweetlou/products/client/seamonkey/macos/10.x/ppc/2001-10-04-04-0.9.4/Netscape6forMacOSX.smi.bin
I work with jj today in his cube and once we create a 'styl' resoruce for the japanese TEXT resource and associate a font id with Japanese range (sorry, I for get the font id number, but I think jj know, it is docuemnt in the Inside Mac - Text page 1-50) it display Japanese license without problem.
fixed. Mozilla EULA (English) added to the disk image in todays' build, available here: ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-10-11-04-0.9.4/MozillaforMacOSX.smi.bin
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Someone raised a good question which should be addressed -- How and where should Netscape license text be checked into the Netscape builds and where should a Mozilla EULA be stored (which raises another question of what should be in a Mozilla EULA for presentation to Mozilla end users -- which should not be the same as a Netscape EULA). Perhaps it is not a clean technique for us to attach a Netscape license text to a Mozilla bug. What text is in the Mozilla build referenced by jj? If it is from the Mozilla trunk and not Netscape branch, then the license text should not be the Netscape license.
I'll answer Mike's questions here, but any follow-up to this discussion should take place outside of this bug, which is about including the license agreement dialog (whatever its content is) into the MacOS X disk image. Mozilla EULA comes from mozilla/LICENSE, on whatever branch/trunk the rest of the source gets pulled from. Netscape EULA comes from ns/xpfe/global/resources/content/license.txt
Verified on build 2001-10-11-04-0.9.4 (using Netscape6forMacOSX.smi.bin) Very cool!
Status: RESOLVED → VERIFIED
Attachment #50806 - Attachment is obsolete: true
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: