In the installer downloads for Windows and MacOS it seems to me that if Talkback were used alot more people would have Talkback to make fixing bugs easier. This is just an idea for helping eliminate bugs faster and easier without having to come up with an entirely new idea or major project.

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

really an enhancement request ->Build config

Bouncing to release guru.

we already have talkback xpi's for the linux mozilla installer. do we have or plan on having talkback xpis for win32 or mac?

I can arrange to have the windows talkback xpi put out on ftp.mozilla.org, so that people can drag-and-drop talkback into their mozilla builds. This might lead to some erroneous data if people use older builds and install newer talkback (since the buildid for talkback is stored in the talkback xpi, not as part of the browser package). I'm not sure how mozilla.org feels about having non-open components as part of their end-user installer options. I'll ping staff.

What's the status on "windows talkback xpi put out on ftp.mozilla.org"? I hate having to download the talkback.zip file and unzip it myself. I just loove the installer.

some nominations for you leaf :) I think that this or bug 63055 would be good for everyone.

looks like talkback needs to be checked into a mozilla/shelf area :)

is putting a talkback.xpi file up on ftp.mozilla.org a good workaround? all you have to do is drag and drop the xpi onto the mozilla build for it to get installed, right? (no, ssu, no mozilla binary shelf!)

is a talkback XPI reusable? If I download the XPI once can I install it in each new daily build that I download? If so then I'd say yes. Maybe we could even set up a page for installing TalkBack (like the old PSM page at iPlanet). If not, and we need a talkback that coresponds with that day's build then we'd need to put the XPI in the directory with the build and do it manually. This could be alleviated when we have a stub installer for win32 right? Then you could just drop the XPI in with the others XPIs and we could have an install option in the installer.

talkback.xpi files have the buildid inside them, so you need the right talkback.xpi to go with the right build or the reported problems while still somewhat useful, will throw of the analysis so it should be avoided.

Not sure I understand: is there a problem in getting the talkback.xpi included into the win32 installer?

It's a build ordering issue. All the talkback source is in the ns tree; to build a talkback mozilla build, we have to build mozilla, then build netscape commercial (NC), then stuff the talkback bits that NC generated into the mozilla dist for repackaging into the mozilla .zip file. Building the installer right now is a one-configuration kind of thing. To generate an installer with talkback requires calling a different (as yet unwritten) script to build the installer with talkback as an option... we can't make the talkback xpi a requirement for the generic mozilla installer build, because, guess what? talkback isn't open source, and requiring it would put non-netscape distributors out of business. So, it's coming, just relax... ssu, can i get your help with a script to make a mozilla installer with talkback?

sure. just send me some email.

the win32 installer has been updated with a "place holder" talkback.xpi file. All that is needed is to replace this "place holder" with a real talkback.xpi in the installer. The installer will not know the difference.

forgot to mention one thing. When the real talkback.xpi replaces the place holder one, the installer's config.ini needs to be updated with the new talkback.xpi's size information. Or else the installer might run out of disk space at the actual installation time. I can help automate this process when you're ready to get this in place.

the talkback.xpi is a static file. the only thing that changes is the master.ini and inside that only the date and occasionally the productid (by only a few bytes). Wouldn't it be easier and faster to hardcode the talkback.xpi size and not worry if it's off by a few bytes? Or will the installer routine that checks for file corruption not like that?

I was going to suggest hardcoding the size, also. Should the talkback install really include the master.ini? If it were included in the browser instead then people would only have to update each day's browser.xpi and wouldn't have to re-install talkback every day (windows appears to include master.ini in both, at least in commercial). By removing master.ini from talkback.xpi then people who initially didn't download talkback could safely install a relatively static one offered on the site without having to worry about matching builds exactly.

adding shiva for his talkback knowledge. I'm thinking we shouldn't put the master.ini in the browser.xpi because if people choose not to install talkback, they wouldn't want/need that file.

If people choose not to install Mail they still get all the mail skin and locale chrome. Adding an extra tiny master.ini is insignificant if we gain something by it (and I guess that's what is open to debate). I guess the disadvantage of taking it out of the talkback.xpi is that non-official builds of mozilla won't be able to generate a master.ini, so if those are crashing and people install talkback they still won't be able to generate stack traces. Wait, what am I saying -- we wouldn't want them to! who knows what their build is, the stack data could be worse than useless.

hard coding the size information is fine by me. Just point me to a real talkback.xpi for mozilla, and I can hard code it in config.ini.

win32 only, mac bug is 68643. setting 0.9.1 since we want this in as soon as possible. ssu - look at any of the talkback.xpi files on sweetlou. lately they seem to be 248286 bytes. did you already make that change to the mozilla installer? I seem to recall seeing Talkback in this morning's installer. Once the installer is changed, leaf just needs to change the automation to deliver the talkback.xpi to the mozilla server. cc'ing kysmith in case he has time to hack around in there before leaf does.

The mozilla installers has had a dummy talkback.xpi since 3/14. The ns installers should not have been affected, meaning whatever they had for talkback.xpi (before my check in to this bug) should still be the same.

In other words, there should be nothing stopping this from being 0.9 -- you just need to push the ns talkback.xpi to the server. Optimistically setting the target milestone back to 0.9 as this would be a perfect branch task.

moving back to 0.9.1. please don't change the target milestone for my team's bugs. this is a nice to have for 0.9. if leaf or kysmith have time to work on it, great, but we're not holding 0.9 for it, so it shouldn't be targeted for 0.9 at this point. we don't deliver a stub win32 installer or standalone xpi files for win32 right now, so implementing this means changing the automation (to both deliver the stub and standalone xpi files, and repack the blob with the correct talkback.xpi) which means lots of testing which means lots of time. the only part of this anyone should expect to be done for mozilla 0.9 is to manually repack the blob (installer + xpi files) to include the correct talkback.xpi file so the official mozilla 0.9 win32 installer build has talkback in it.

*** Bug 77444 has been marked as a duplicate of this bug. ***

i hate when i forget to resolve bugs.

it sure is...

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.