Closed Bug 253750 Opened 18 years ago Closed 17 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)

x86
Windows 2000

Tracking

(Not tracked)

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: 17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.