Closed Bug 253750 Opened 21 years ago Closed 20 years ago

Talkback doesn't launch anymore on crash for non-installer builds due to compreg.dat file (which doesn't have Talkback registered)

Categories

(Core Graveyard :: Talkback Client, defect, P3)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mcsmurf, Assigned: chase)

References

Details

(Keywords: regression)

To reproduce: 1. Download a current nightly Then try to open http://bugzilla.mozilla.org/attachment.cgi?id=154607&action=view (should crash) or go to espn.go.com, block main image under the main headline, reload, click right on it (might crash now), click unblock image and click right again on the empty space (should crash now). Also Mnyromyr (the one from irc if you don't remember) can confirm this, regression timeframe unknown
I picked up a stub installer build for today's 2004-07-30-09 on Windows XP. Must be limited to the zip?
I don't think we package Talkback with the .zip files. You have to run the installer in order to get Talkback. Frank: Did you run the stub or full installer? If not, try that and see if it works for you.
(In reply to comment #2) > I don't think we package Talkback with the .zip files. You have to run the > installer in order to get Talkback. Jay, I use only Suite ZIP files and they contain TalkBack.
As reported in bug 253479, Talkback comes up with the 1.7 release (ZIP), but not with 1.8a1 (ZIP) and newer nightlies (ZIP). (I don't use installer builds.)
I downloaded actual nightbuild ZIP file and crash Mozilla. With just unzipped Mozilla, TalkBack didn't launch. If I deleted components/compreg.dat file, TalkBack launch normally. Maybe we just shoudn't pack compreg.dat into builds?
> If I deleted components/compreg.dat file, TalkBack launch normally. Yes, that seems to help.
When you install a .zip of Mozilla, do you still have the talkback.exe and master.ini files in your components directory? We have seen weird behavior where if you install a version Mozilla with Talkback and then install or unzip another version on top of the same install directory, the old Talkback still works (probably because there is a registry entry for Talkback at that location).
(In reply to comment #7) > When you install a .zip of Mozilla, do you still have the talkback.exe and > master.ini files in your components directory? I unzipped in a new folder, so no talkback.exe or master.ini there.
Re comment #7: > When you install a .zip of Mozilla, do you still have the talkback.exe and > master.ini files in your components directory? I do not "stack" builds, each gets its own fresh directory. :)
So Karsten and Adam, both of you are saying that the talkback.exe and master.ini are there, but Talkback won't launch unless you remove the compreg.dat file? Leaf just told me we should have Talkback in the Trunk .zips. Maybe he can help out here. CC'ing him.
I see: 15329 03-22-04 14:56 mozilla/components/talkback-l10n.ini 1355 03-22-04 14:58 mozilla/components/talkback.cnt 401408 03-22-04 14:58 mozilla/components/talkback.exe 32928 03-22-04 14:58 mozilla/components/talkback.hlp in the mozilla-i586-pc-msvc.zip file found at: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-07-30-14-trunk/mozilla-i586-pc-msvc.zip So i am sure talkback is included. As has been alluded, compreg.dat being present prevents mozilla from re-registering components. Removing compreg.dat will cause a hit in the initial startup time, but seems a small price to pay for talkback data. I'll add automation to remove compreg.dat for talkback builds.
>I'll add automation to remove compreg.dat for talkback builds. doesn't help if people unzip over a previous install... Does the .zip contain a .autoreg file?
(In reply to comment #12) > Does the .zip contain a .autoreg file? No, if i create one myself before starting Mozilla the first time, it seems TB gets registered (the .autoreg file gets deleted afterwards of course) and TB will get launched on crash. So it would be a better solution to include a .autoreg file?
I do think that would be better. didn't the zip/tar.gz builds use to include it?
(In reply to comment #14) > I do think that would be better. didn't the zip/tar.gz builds use to include it? Downloaded up to 2003-12-26 one nightly per month, i didn't see any .autoreg file. Maybe this has been broken for a long time now (or i downloaded the wrong builds)?
> unzip -l mozilla-win32-talkback.zip |grep autor 0 12-09-02 17:46 bin/.autoreg this is from http://archive.mozilla.org/pub/mozilla/nightly/2002-12-09-08-trunk/mozilla-win32-talkback.zip
(In reply to comment #16) > > unzip -l mozilla-win32-talkback.zip |grep autor > 0 12-09-02 17:46 bin/.autoreg > > this is from > http://archive.mozilla.org/pub/mozilla/nightly/2002-12-09-08-trunk/mozilla-win32-talkback.zip Ah, it seems only builds with bin (bin\mozilla.exe, etc.) structure include it and those with the mozilla (mozilla\mozilla.exe, etc.) structure don't. So probably that builds were made by another machine.
I tested 1.8a2 release ZIP build and it's also affected by this bug. If we want some bigger TalkBack feedback from 1.8a3, this should block its release. Requesting it.
Flags: blocking1.8a3?
Flags: blocking1.8a3? → blocking1.8a3+
Reassigning to Leaf. I will be more than happy to help out, but I still haven't been given access to the build system.
Assignee: jay → leaf
Flags: blocking1.8a3+ → blocking1.8a3-
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040903 the bug is showing again on zip builds. deleting compreg.dat was needed to get talkback working. Was using 1.8a3: 2004082608 before, also a zip nightly, talkback was working. This issue seemed to be fixed for a while, now it´s coming back? My way of installing zips: rename the old mozilla directory to the buildid, so now I´ve got a folder M040826-08, previously named mozilla. Then I unzip the zip, so the folder mozilla gets recreated in the same place. And I´ve got a shortcut to the mozilla.exe in this place. This way I can have a lot of nightlies for regression testing.
*** Bug 258482 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041007 Bug still unfixed, workaround still working, if you remember workaround: delete compreg.dat
over to chase
Assignee: leaf → cmp
Priority: -- → P3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041024 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0 After download, unpacked zips in new, empty folder created by the unzipper, started and tested testcase of a crasher bug. Both were nearly immediately crashing, Mozilla a tad slower. Talkback didn´t come up, though found in components directory. Deleted compreg.dat, then Mozilla´s talkback was working, Firefox´s not. File master.ini was included in the mozilla zip package, was missing in the Firefox one.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20050107 zip build creating a fresh directory. crashes on testing crasher bugs, DocWatson comming up, not Talkback. After deleting compreg.dat, Talkback is generating reports. Starting yesterday, reports aren´t accepted by the talkbackserver, seems to be a server problem, though the server page tells all is well. The most recent incident id submitted is 2977145. youngest triggertime: id 2977142 Trigger Time 2005-01-07 10:23:08.0 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=2977142
Summary: Talkback doesn't launch anymore on crash → Talkback doesn't launch anymore on crash for non-installer builds due to compreg.dat file (which doesn't have Talkback registered)
Depends on: 265492
wfm (means crash with talkback) Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050806 SeaMonkey/1.0a zip unpacked in new created directory. maybe fixed by: Bug 265492 Packages sometimes accidentally contain compreg.dat, xpti.dat, or chrome.rdf Bug still exists in non-windows builds: Bug 279993 Talkback not working in non-installer builds after 2005-01-15 because package contains compreg.dat Bug 301000 Talkback doesn't work in seamonkey (due to rebranding)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.