Closed Bug 210251 Opened 21 years ago Closed 17 years ago

Talkback says: "The Agent is unable to connect to the server.", BUT incidents are being sent

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: david, Unassigned)

References

(
URL
)

Details

(Whiteboard: See comments 34 & 70; Future: comment 89)

Attachments

(1 file)

New info: Each failed attempt pegs the CPU. See attached.
120.94 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529

Mozilla crashed (for reasons I'm still examining).  Talkback queued an incident
report.  When I selected the Send button, a report appeared to be sent (e.g.,
bytes were indeed going through my modem).  

However, an error popup appeared with the message: "The Agent is unable to
connect to the server. Please check your Proxy Server settings or try again
later."  I use a dial-up connection without any proxy server.  

Reproducible: Always

Steps to Reproduce:
1.  Crash Mozilla with Talkback enabled.  
2.  Respond to prompts for further information.  
3.  Select the Send button.  

Actual Results:  
See details.  

Expected Results:  
Notification of successful transmission of error report.  

I list this as a Major error because it prevents the Mozilla organization from
receiving a report about a crash.  The crash itself might be Critical.
-> jay
Assignee: namachi → jpatel
QA Contact: chofmann → janc
After a lot of testing, this bug seems invalid.  What we found is that the
incident is actually being sent and can be queried for...but the status is not
updated on the Talkback client.  It appears as if the incident was never sent
from the users point of view, but in reality, it was sent and processed fine.

I believe we already have a bug logged for fixing the real problem:  making sure
the Talkback server updates the incident status on the Talkback client.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
I request the number of the bug cited in comment #2 so that I can track it.  
Reopening, invalid bugs don't get looked at.
Jay should find the bug, put it in this log, and 
mark this invalid again.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
We have a bug logged in bugscape to address this issue:
http://bugscape.mcom.com/show_bug.cgi?id=21753

Returning to invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → INVALID
Someone needs to explain how closed bug #21753 -- marked WORKSFORME three years
ago -- covers this problem, which I saw this year with v1.4.  I also request an
explanation of how the description of bug #21753, which never mentions Talkback,
addresses a Talkback problem.  

It's not that I insist that I have a unique problem here.  It's just that I want
to track the problem and need a legitimate bug number if this one is a
duplicate.    I cannot track a repeatable problem via a closed bug.  

Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Note that *bugscape bug 21753* is the bug here, not a bugzilla bug.
The title of this bug is "Talkback Agent submission status not updating",
and it looks to be a bandwidth problem.  This bug is assigned to me,
if you want to know more please followup with me in an email.

If I am correct there has been a bugzilla/bugscape misunderstanding,
we should either point to the bugscape bug and leave this open,
or mark this a dup.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Aha!  As a relative novice with Mozilla, I thought "Bugscape" was just someone's
nickname for Bugzilla.  I didn't realize that Bugzilla and Bugscape are two
distinct error report database systems.  

I might be a novice with Mozilla, but I have over 10 years experience with
software configuration management and over 34 years with software testing
(overlapping the CM).  Since Bugscape appears to be a system internal to
Netscape and not publicly available for browsing, I strongly suggest that this
report remain open in Bugzilla until the problem is fixed.  That way, outside
users searching for open Talkback bugs will find it.  That might reduce the
occurances of duplicate reports.  

Of course, the Bugscape report should be updated to reference this Bugzilla
report (just as this Bugzilla report references the Bugscape report).  That
mutual cross-referencing will ensure that both reports are closed when the bug
is actually fixed.  

I've seen this problem using Mozilla 1.6. I had two program crashes last night
and they could not be sent then. They still can't be sent today.

I'm using a 56K modem and Talkback exchanges data for 20 to 30 seconds before
failing. After failing I did a netstat in a MSDOS window. This showed a
connection to talkback-s01.websys.aol.com:80 with state TIME_WAIT.

P.S. I'm using windows NT so it's not only a problem on windows 98.
The following is prompted by recent discussion on the
<news:netscape.mozilla.user.general> newsgroup:  

1.  There is a known, recognized, real problem in Talkback (Bugscape bug 21753).  

2.  The affected (afflicted) Talkback version is delivered and installed with
Mozilla.  

3.  More than one Mozilla user has seen this problem.  

4.  Because of the problem, some (many?) Mozilla users disable Talkback, thereby
depriving Mozilla developers of valuable crash data.  (I know I won't enable
Talkback until this is fixed.)  

Therefore, this is a Mozilla problem.  

Even if the bug is entirely within Talkback, there is value in keeping this
Bugzilla bug open.  It provides visibility into the problem for those who cannot
access the Bugscape database.  It also provides a reference which might reduce
the number of duplicate bug reports; those who follow instructions and search
for an existing bug report before writing a new report often limit their
searches to open bugs (NEW, ASSIGNED, or REOPENED).  At least, this provides a
reference against which duplicate bugs can be closed.  


According to the summary of mozilla.org staff meeting for 23 February, "Talkback
is working on Windows".  Is this in 1.6 or 1.7?  What is the status of Bugscape
bug 21753?  
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219] (W98SE)

I was able to send one report on 26/02/04,
but two are failing since 14/03/04 :-(

Updating:
+(b) bug 189702, they look like duplicates but I'm only creating a "link" for now.
Depends on: 189702
(In reply to comment #12)
> [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219] (W98SE)
> 
> but two are failing since 14/03/04 :-(

Here is what my proxy (Proxomitron) says:
{{
+++GET 26+++
POST /spiral-bin/Collector.dll HTTP/1.0
Content-Length: 152
User-Agent: talkback/1.0; Win32
Content-Type: application/x-spiral-fcmp
Host: talkback.mozilla.org
Connection: keep-alive
Posting 152 bytes...

+++RESP 26+++
HTTP/1.0 500 *** collector timeout ***
Date: Mon, 15 Mar 2004 22:30:03 GMT
Content-Type: text/plain
Connection: close
Server: Netscape-Enterprise/6.1 AOL
Via: 1.1 becquerel (NetCache NetApp/5.3.1R2DEBUG12)
+++CLOSE 26+++
}}
When the 500 error is received, TB seems to process anyhow, but ends with 'Failed'.

Note that I don't even now why TalkBack uses my proxy: all the TB proxy settings
are empty/default.
Well ... it "silently" uses my MsIEv5.0 setting :-(
And doesn't work any better when removing my proxy use.
1.7 beta, Windows 98, just had a crash, can't send the report.
Flags: blocking1.7?
if posting to this bug please add as much information as you can on specifics
about Operating System, Network, Firewall, Proxy Configurations where this is
happening to help us sort out what might be going on.
Referring to comment 14, I am on a straight dial-up connection, no firewall, no
proxy.
I have had a problem with Talkback not sending on both 1.7a and 1.7b (Build
2004031616).  I am running Windows 98 in a small office with no proxy using
cable modem shared through a Linux box (Devil-Linux firewall).  I have not had a
problem with older versions of Mozilla/Talkback on this setup but I am having a
problem with the last two versions of Mozilla/Talkback (1.7a and 1.7b)
Flags: blocking1.7? → blocking1.7-
This still appeared to be a problem with 1.7a and 1.7b.  If this remains a
problem with 1.7RC1, I strongly question why this is not a blocker for 1.7 given
the significant promotion of TalkBack for that version.  

From the 1.7RC1 "readme" at
<http://www.mozilla.org/releases/mozilla1.7rc1/README.html>: 
  "Official Mozilla 1.7 RC 1 builds for Windows and Linux contain the Talkback
crash reporting utility. To help us make 1.7 the most stable release yet, please
submit your crash reports."  

If I see this is indeed still a problem, I will disable TalkBack.  I would also
recommend that everyone else do the same.  

Reassigning to Shiva.  He might have more information about this.

For those that are seeing a problem with submitting Talkback incidents with
Mozilla 1.7rc1, please include the following information in your posts:

1. Platform - os and version
2. Connection - dialup/broadband and isp
3. Proxy information
4. Firewall information
5. Talkback Incident IDs and their status (run talkback.exe in your components dir)
6. Time of crash and attempted submissions/errors

Look up your incidents (any ids you see when you run talkback.exe, regardless of
their status) at http://talkback-public.mozilla.org and see if they are
populated in the database.  We have seen cases where even though the user sees
the "Failed" error message, they're incidents are still submitted ok.  It would
be helpful to find out how many people's incidents fall into that category.

If you know of others have this problem, please have them add their information
into this bug.  Unless we get a fair amount of people to give us there input,
this problem will be difficult to debug.
Assignee: jay → namachi
QA Contact: jcarpenter0524 → jay
Since I posted (above) I have submitted a couple of crash reports with Talkback
successfully. 

This is not a blocker.
I'm having the same difficulty.

Platform: Windows 2000 SP4
Connection: dialup
Proxy: The Proxomitron for capturing HTTP headers (the problem occurs even
       without the proxy)
Firewall: Kerio Personal Firewall 4.0.16  (the problem occurs even without the
          firewall)
Last three connection attempts:
    June 14, 2004 15:10:00
    June 14, 2004 15:10:36
    June 14, 2004 15:11:11

1: Talkback has one incident with "in Queue" status and no Incident ID

2: Click the send button

3: Talkback connects to 207.126.111.208 (h-207-126-111-208-mozilla.sv.meer.net)

4: Talkback sends this to the server (followed by the data)
    POST /spiral-bin/Collector.dll HTTP/1.0
    Content-Length: 153
    User-Agent: talkback/1.0; Win32
    Content-Type: application/x-spiral-fcmp
    Host: talkback.mozilla.org
    Connection: keep-alive
    Posting 153 bytes...
    
5: The server sends this response
    HTTP/1.1 200 OK
    Server: Netscape-Enterprise/6.1 AOL
    Date: Mon, 14 Jun 2004 21:39:47 GMT
    Content-length: 85
    Content-type: application/x-spiral-fcmp
    Connection: close

6: Talkback connects a second time to 207.126.111.208
(h-207-126-111-208-mozilla.sv.meer.net)
    
7: Talkback sends this to the server (followed by the data)
    POST /spiral-bin/Collector.dll HTTP/1.0
    Content-Length: 105153
    User-Agent: talkback/1.0; Win32
    Content-Type: application/x-spiral-fcmp
    Host: talkback.mozilla.org
    Connection: keep-alive
    Posting 105153 bytes...
    
8: Talkback displays a dialog message
    The Agent is unable to connect to the server. Please check your Proxy Server
    settings or try again later.

9: The server sends this response
    HTTP/1.1 200 OK
    Server: Netscape-Enterprise/6.1 AOL
    Date: Mon, 14 Jun 2004 21:40:19 GMT
    Content-length: 4094
    Content-type: application/x-spiral-fcmp
    Connection: close

10: Talkback has one incident still with "in Queue" status and still no Incident
    ID

The information I listed above is valid for these versions so far:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040613

Hi,

I'm on 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614
Firefox/0.8 Mnenhy/0.6.0.101', and I've observed the same trouble lately. In
previous releases of Mozilla (pre-1.0, that said), I haven't had this trouble.

The best 'fix' I've found is to go to work, or to school, with a broadband
connection, to upload the reports, but I find after a few days, for some reason,
my Talkback reports start disappearing, unless I receive the incident ID for them.

How odd.

Since I'm receiving a crash consistently for viewing some pages through my
school's EZproxy install -- see
http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=ezproxy for
details -- I've been hoping to have my crashes in this regard reported, but as a
result of the above I've only been able to submit two so far. Hrm.

Cheers,
Jonathan Ah Kit.
I'm on winxp (no proxy, but I do have linksys router) and I think I'm seeing
this too.
Summary: Talkback does not send reports → Talkback does not send reports: "The Agent is unable to connect to the server."
I need to test a theory of mine to see if any of your incidents are being
submitted even though you see the error message from Talkback.  Anyone that has
been having problems sending Talkback incidents, please try this:

1. Crash.
2. Fill out Talkback incident form, making sure to provide a complete email
address (or a unique comment that can easily be queried for).
3. Send.
4. Most likely observe the "unable to connect" error message.
5. Post the email address or unique comment you provided for the crash incident
in this bug.

Once I have a few, I will try to look up your incidents to see if they even get
to the Talkback database.  My testing in the past has shown that incidents are
often being submitted ok, but the user is not getting an update from teh server
telling them that the incident went through...instead, they are seeing this
connection error (making it appear that nothing was sent).
I am pretty sure I am seeing this bug.  Details:
- WinXP Pro, current with all Microsoft updates.  
- Dialup, no proxy.  
- Firewall is Internet Connection Firewall.  
- Time of incident is 10:39 p.m. EDT (0239 UTC July 5).  
- Crash was from Firefox 0.9.1.
- Comments section begins with "5 other tabs open,"
- email=stusarah@telerama.com

It appears that the Agent attempts resending that info every 5 minutes, and has
been doing so for the past 40 minutes or so. (I just killed it, though.)

Let me know (either on this bug or in a separate email) if you need additional
information.

This happened to me on two additional occasions.
First: 2004-07-12 10:23pm EDT (0223 UTC July 13), same machine as in Comment
#26, but with a fresh install of Firefox 0.9.2.  Comments begin with "Firefox
0.9.2 release; WinXP Pro".

Second: 2004-07-13 05:01pm EDT (2101 UTC July 13).  Different machine, also
WinXP Pro, broadband connection, but a first-ever install of Firefox (I used
0.9.2).  The install went OK, but Firefox crashed when importing Saved Forms.  I
am not sure of proxy or firewall info but I can get it.
the server was down. it happens, these days you can even read:

http://talkback-public.mozilla.org/talkback/fastfind.jsp

which says:
The Talkback DB is currently down. Incidents coming in will be queued for
processing when the DB is back up. For now, the query tools will be unusable,
but the Talkback reports are all up.

--
it's wrong, the server started accepting connections w/in the past hour. but it
was accurate for a while.
URL: none
Same setup as in my two earlier posts.	Current IP: 205.201.40.225, and has
been for about the last four hours.
As far as I can tell, this observation has not been previously documented.
(In reply to comment #25)
> I need to test a theory of mine to see if any of your incidents are being
> submitted even though you see the error message from Talkback.  Anyone that has
> been having problems sending Talkback incidents, please try this:
> 
> 1. Crash.
> 2. Fill out Talkback incident form, making sure to provide a complete email
> address (or a unique comment that can easily be queried for).
> 3. Send.
> 4. Most likely observe the "unable to connect" error message.
> 5. Post the email address or unique comment you provided for the crash incident
> in this bug.

I've had a connection attemp fail with the following e-mail value assigned to
the incident: mozilla-crashed@july-30-2004.com
Looks like my theory is valid...

Michael:  I looked up your email address and found an incident (448953).
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=448953

You won't see your email address in the incident report b/c we cannot display
user information on the public site...but that is the crash I found under your
email address using our internal query tool.

Anyone else see an error while submitting?  If you have an email address or ip
address, I can look it up to see if it was processed...
Today (5 Aug 04), Mozilla crashed on me.  Talkback operated.  I got back the
error message I reported when I originally submitted this bug.  

I then went to the Talkback FastFind capability at
<http://talkback-public.mozilla.org/talkback/fastfind.jsp>.  There, I found my
error report, incident #492269.  This confirms the conjecture in comment #2 and
repeated in comment #25: The problem lies in the failure of the Talkback client
to recognize a "successful receipt" response from the Talkback server.    

My connection is not through any proxy or firewall.  It is a dial-up.  
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040803
I tried setting the TalkBack sending option to "Only after I select Send on the
Agent History window". After the next crash, I queued up the report then clicked
the send button on the Agent History window. This time the status of the
incident was changed to "sent". I'm wondering if attempting to send from the
Agent Prompt dialog as opposed to the Agent History window might make a
difference. (A race condition of some kind?)
Sending the Talkback report from Agent History window does not help.  This has
always been the option I use, and I still see the problem.  

As conjectured by Jay Patel and others, the problem is in the interface between
the client and server (e.g., see comments #25 and #31).  The client fails to
recognize the acknowledgement signal from the server that indicates the report
was received.  Yes, this might indeed be a timing problem since it does not
always happen.  
This has happened to me as well.  It is either a timing or time-out issue.  It
only happens with modem connections.  The same incident can be sent from the
same computer when actually connected to the network using exactly the same proxies.
My problem, submitted as bug 264445 because my search for an existing bug didn't
turn up anything, is identical. And I am indeed on modem, on a laggy Tiscali
connection.
*** Bug 264445 has been marked as a duplicate of this bug. ***
This bug appears to be alive and well as of:

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.

Wasting 45 minutes of "willing bug reporter" time on a simple notification
failure is Rude&reg;.  Does anyone know why we can't issue a DB query after an
update failure to kludge this back into functionality? 

-Greg




Personally I find this bug so important to tackle, deal with and fix that I
believe it should get Severity: blocker for several and obvious reasons. People
with dialup connection can crash and all they'll get is the impression Mozilla
does not even work as expected with the reporting of the error/crash incident.
Mozilla.org should expect more Firefox users (millions!) in the next few weeks;
this talkback tool should be in a much better working order IMO.
Repeated failures (along with pegging of cpu) makes people turn off Talkback: I
know I have.

How sure are we that
- (#c25) "incidents are being submitted even though you see the error message
from Talkback (...) incidents are often being submitted ok, but the user is not
getting an update from teh server telling them that the incident went through"
and (c#32) "The problem lies in the failure of the Talkback client to recognize
a 'successful receipt' response from the Talkback server."
- this involves only Win98. I have seen this talkback reporting problem for over
a year and I use XP Pro.
 
If we all agree this is a blocker bug (and I sincerly believe it is) and unless
I hear strong objections against such change, then I'll make that change in the
Severity field and I'll flag-request as blocking-aviary1.0.
URL: http://talkback-public.mozilla.org/
Whiteboard: See comment #34 for summary
How difficult can it be to just make the Talkback Agent upload it's error report
as a regular <input type="file"> POST form, and have that submitted to some
database over at mozilla.org, with a simple Content-type: text/plain body with
an "OK" response in it? KISS (Keep It Simple, Stupid)!
I have the same problem, the error report takes ages and still doesn't go. I
have Firefox 1.0PR
Those of you who say your Talkback report "doesn't go", have you gone to
Talkback FastFind at <http://talkback-public.mozilla.org/talkback/fastfind.jsp>
and verified that the report was not received and entered into the database?  
RE comment #42.  It is not possible to tell because you only get the talkback ID
if it says it was successful, and every other kind of query I have tried on
talkback-public in the last month has resulted in a Database error.
If you know the approximate time when you tried to send a Talkback report, you
can indeed query Talkback FastFind.  (I just did it.)  It's best if you always
enter a Comment when sending a Talkack report, but it's not necessary.  

Under QuickSearch, do the following:  
1.  Enter the date of the attempted send for both Start Date and End Date.  
2.  Enter an hour before your attempt for the time in Start Date and an hour
after your attempt for the time in End Date.  Use local time (as defined by your
computer).  
3.  For Search By, select the Stack Signature radio button, Contains from the
selection list, and enter a colon (:) in the search field.  (It seems every
Stack Signature contains at least one colon.)
4.  Select the Search button at the bottom of the "Customize your search" area.  

You will get all Talkback reports submitted during the two-hour time period you
specified.  If you entered a Comment before sending the Talkback report, you
should be able to find your own report -- if it was received.  
re comment #44.  The problem was not that I did not know how to do queries, just
that any query I did returned a server database error.  It appears to be working
much better today.
So we are absolutely sure that

- talkback crash data is submitted despite the error message from talkback
server saying it was not
- not just windows 98 is affected by this bug

right? Yes? No?
Thanks to all of you that have provided more information about your particular
issues.  This has been a bug in the Talkback component forever and is something
that we have not been able to fix yet.  

Since Talkback is a 3rd party component that Mozilla only has a license to use,
we do not have access to the source code to fix it ourselves, and since it is no
longer supported by SupportSoft, there are few engineers around that have access
to that code.  With that said, we are trying our best to get a new version that
will fix the problems many of you are seeing.

In the meantime, there is not much we can do about the error messages, but as I
said earlier, 99% of your crashes ARE being successfully sent to us.  If you
want to verify this, please do as Davis has suggested.  Chances are, you will
see your incident in the results.

Sometimes the Talkback server will be down or have a backlog, so check the
Talkback Server Update message.

(In reply to comment #46)
> So we are absolutely sure that
> 
> - talkback crash data is submitted despite the error message from talkback
> server saying it was not

Not 100% sure, but pretty confident that most of the data is in fact sent in.

> - not just windows 98 is affected by this bug

This seems to happen all various platforms and os versions.  Certain things like
dial-up connections or sending through proxies seem to increase that odds of a
person seeing this problem.
Summary: Talkback does not send reports: "The Agent is unable to connect to the server." → Talkback says: "The Agent is unable to connect to the server.", BUT incidents are being sent
Flags: blocking-aviary1.0?
OS: Windows 98 → All
OS: All
blocking-aviary1.0 ? Flag
Veerryy interesting!  

When I open Talkback and select Help > About Talkback, the display contains a
link to <http://www.fullcirclesoftware.com>.  This is a defunct domain.  

Comment #47 refers to SupportSoft.  When I select Help > About Mozilla on the
Mozilla menu bar, the display contains a line that states:
"This software may contain portions that are copyright © 1998-2002 SupportSoft,
Inc. All Rights Reserved." with a link to SupportSoft.  A search of the
SupportSoft Web site on "Talkback" is unsuccessful.  

I suggest the following:  

1.  Given the defect in the Talkback client and the lack of support to correct
that defect from SupportSoft, the Mozilla Foundation should renegotiate or
terminate its licensing arrangement with SupportSoft.  (SupportSoft should
indeed declare Talkback to be "public domain" software.)  

2.  The Mozilla Foundation should consider developing its own replacement for
Talkback.  If this feature is not sufficiently important for that effort, then
perhaps Talkback itself is not important enough to be included in Mozilla
products.  

3.  The initial, default setting for Talkback should be "Turn Agent Off" in
Firefox before the defect discourages new Firefox users and interferes with
marketing attempts at mass deployment of the product.  

A talkback (reporting crash data) feature in good working order is very much
important for Mozilla for all kinds of purposes, benefits. Such feature
justifies amply the efforts to develop it.

Out of the ten remaining FF 1.0 blocker bugs is bug 265564; also out of four FF
1.0 blocker nominated bugs is bug 265806. So with this one, that's 3 bugs out of
13 related to talkback.
Interesting: On my WinNT4 box with proxy for internet access only the Firefox
0.10.1 talkback has problems (error message, status 'in Queue' but incidents are
being sent). If I let crash my Mozilla 1.8a5 I can send the report and it shows
the successful sending with status 'sent'. Very strange. File versions of
talkback.exe and the settings are the same. With FF TB ID 1511390 wasn't sent
according to TB client, but it appears in TB DB (found by comment). If I see the
last comments it seems that only FF is affected.
*** Bug 265766 has been marked as a duplicate of this bug. ***
re: https://bugzilla.mozilla.org/process_bug.cgi#c49

1.Supportsoft has graciously donated the talkback software for use by the
mozilla project. We thank them for this donation.

2. The software has proven invaluable to making Mozilla, Firefox, and
Thunderbird some of the most stable appllications ever produced, espcially when
you consider the remarkable progress from early milestone like 0.6 and before. 
Will will continue to use tools that are useful to improving mozilla code where
ever, and when ever we find them.  

3. Where huge gaps in tool coverage and funtionallity exist the project has a
history taking on the development effort to fill those gaps (witness bugzilla,
tinderbox, bonsai, etc...).  At this point talkback provides us with adequate
coverage in our contining effort create stable applications and find and fix
crash bug regressions quickly and efficiently.    

4. These things being said, we will continue to make talkback better within the
terms of the licensing agreement and the engineering effort we can put in to
adjusting talkback client settings and management of the servers, but we
understand there are limitations to the adjustments that can be made.  

5. We would consider other tools that would allow us to continue to make the
great progress that talkback has allowed in creating stable and reliable
applications, if and when those tools become available.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Re comment #53:  

Obviously, items 1 and 2 in my comment #49 are invalid.  It's not the first time
I've been wrong; and it won't be the last time.  :)  

Pending resolution of this bug, however, I still think the initial, default
setting for Talkback should be "Turn Agent Off" for Firefox.  The user audience
Mozilla is trying to attract with Firefox may not be sufficiently sophisticated
to follow the discussion here in this bug and to understand what is really
happening.  This could easily discourage them from using and recommending Firefox.  

When the operational, final release of Firefox occurs, crash bugs should then be
quite rare.  While Talkback should be included with the product, having it
enabled ("Turn Agent On") should not have the importance it has prior to the
final release.  

Further, this whole problem needs a user-oriented explanation in the Firefox
release and installation notes.  
(from comment #53)
> 4. These things being said, we will continue to make talkback better within 
> the terms of the licensing agreement and the engineering effort we can put in
> to adjusting talkback client settings and management of the servers

Fixing this bug before millions of Firefox users realize that not only they
crash but they can't even report useful data which could help fix their crashes
seems to me rather urgent. Mozilla.org products lose credibility and support
when people turn off talkback agent.

(In reply to comment #54)
If you turn it off by default, how are unaware users going to know about such
feature, how to turn it off, to use it, etc..? Regardless of the default setting
for talkback, mozilla.org needs a reliable feature in good working order.
Turning it off by default does not solve anything anyway.

> this whole problem needs a user-oriented explanation in the Firefox release 
> and installation notes.

This whole problem deserves a fix quite soon, if possible, more than explanation
otherwise efforts+energy to develop another talkback reporting tool. On-going
development on several products (Suite, FF, TB, Camino, etc.) in mozilla.org
certainly justifies this.
(In reply to comment #51)
Now the same happens for Mozilla 1.8a5 build 2004110705 on WinNT4 for me not
only FF. Error but incident is sent.


(In reply to comment #44)

I have the same problem with FF 1.0 on ADSL connection.

> If you know the approximate time when you tried to send a Talkback report, you
> can indeed query Talkback FastFind.  (I just did it.)  It's best if you always
> enter a Comment when sending a Talkack report, but it's not necessary.  
> 
> Under QuickSearch, do the following:  
> 1.  Enter the date of the attempted send for both Start Date and End Date.  
> 2.  Enter an hour before your attempt for the time in Start Date and an hour
> after your attempt for the time in End Date.  Use local time (as defined by your
> computer).  

Actually, this doesn't work, you have to enter time in talkback system zone (PDT
?). I am in a GMT-1 zone and a report that has been sent at around 12:40 local
time is marked in talkback-public lookup as received on 02:39
Blocks: 238292
jay: any progress with your attempts at getting this fixed mentioned in comment
47?  is the info from http://bugzilla.mozilla.org/show_bug.cgi?id=189702#c35
correct?  if so, the fix should be trivial.

i'm seeing this issue intermittently today with the talkback that comes with
firefox 1.0.1.  i submitted a couple of reports successfully at about 11a PDT. 
then i had to retry a couple.  then i had a few queued up at once which seemed
to exacerbate the problem.  while i was reading through this bug, though, the
talkback client finally reported that they were sent and the timestamps looked
to be from the time i originally tried to send them.

re: the database errors mentioned in comment 43, i filed bug 286948.
No longer blocks: 238292
Marc: No news yet on a Talkback upgrade.  I will update this bug if I hear
anything about a new version that might have this problem fixed.
Still occurs on Firefox 1.0.2 on Windows XP SP2.
Here's a variation on the myriad bugs about Quality Feedback Agent being unable
to connect to the server. First, I've gotten the "unable to connect" error
virtually every time, ever since I first installed it with Mozilla all the way
through Firefox 1.0.2 (Win2k). Often it would go through when I opend Quality
Feedback Agent and manually hit the button to send the reports. But now, with
Firefox 1.0.2, it won't ever connect.

Regardless, the really weird part (which I have yet to see mentioned here) is
that every time it tries to connect, my Ethernet connection gets momentarily
disabled and then re-enabled and Windows brings up a help bubble saying
something like "Ethernet disconnected" and then a second later it changes to
something like "Connection established." In other words, it acts as if I
unplugged my Ethernet cable, then reconnected it, which I'm obviously not doing.

Just a guess, but this could have something to do with the bandwidth being maxed
out that I've heard people talk about.

Sorry for the long-winded rambling to get across a couple of minor points. Hope
this helps.
Just another gentle reminder that this bug is really well over four years old,
and is now being seen by potentially millions of new Firefox and Thunderbird
users.  It is being tracked by both Bug 210251 and Bug 189702.  I cannot discern
any significant difference between these two, and between either one and the
original Bug 60968 (as well as many dups).  Hence I am cross-posting this update
in both.  (Continuing work on Talkback itself is tracked in Bug 238292.)

Once, after a crash independently on Fx and Tbird, I witnessed both instances of
Talkback trying unsuccessfully to complete.  While sends usually get through
(check via http://talkback-public.mozilla.org/talkback/fastfind.jsp), my PC is
at 100% CPU for ~ 75 seconds every few minutes.  This is absolutely unacceptable
to the average user.

Because of this, and for reasons I reiterated fully seven months ago
(https://bugzilla.mozilla.org/show_bug.cgi?id=189702#c39), I am going to try to
mark both Bug 210251 and Bug 189702 as Critical, if I can, and if I cannot, I
hereby request that someone with that authority to please do so ... or give a
cogent reason why not.  

If there is anything we end-users can do to help, please let us know.

WinXP Pro SP2, 933MHz Intel P3, dialup.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 
Firefox/1.0.3, TBird 1.0 (2004120606), Talkback 2.2
Blocks: 238292
stusarah@telerama.com: thank you for the useless reminder, please don't do that
again. this bug while not amazingly long is more than long enough.

as has been indicated repeatedly in this bug there are very few people who can
do anything about this problem, and while it might not have been stated, they
are not under the control of mozilla foundation, so they do work within
constraints of other tasks, and clearly fixing this bug is non trivial.
complaining will not get anything done. before commenting, people really should
read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

further, there's no way that we're going to block a release for this bug, it's
been around forever as people have discovered and we get hundreds of good bits
from people. also, the release installers for windows actually have a tendency
to automatically choose *not* to install talkback, so the concern about
affecting average end users while valient is mostly misguided.
No longer blocks: 238292
*** Bug 293122 has been marked as a duplicate of this bug. ***
Blocks: 238292
*** Bug 311118 has been marked as a duplicate of this bug. ***
*** Bug 312735 has been marked as a duplicate of this bug. ***
is this fixed yet?
*** Bug 324032 has been marked as a duplicate of this bug. ***
Same here on my computer....

I've got DSL over a Siemens Gigaset SE515 dsl Router. 

I deactivated firewall of that router, but same problem. 

I tried a fresh profile, fresh install of FF, tried it on another computer - but it doesn't get any connection!
We know this is a really old bug, and the sad truth is that there is nothing we can do about it at this time.  As I have tried to explain in numerous bugs, Talkback is licensed to us to use in it's current state...we do not have access the source code to fix bugs, add features, etc.  Yes, that is unfortunate, but it does the job, most of the time. ;-)  We get a lot of great data from our users that allows us to improve the stability of all Mozilla products.

This is clearly a bug in the network code for the client-server transactions and we have narrowed it down to some sort of timing issue...but as I said, this cannot be fixed.  I have not seen the code nor been given the opportunity or resources to test it.

We do know that not all users are seeing this problem (we get close to 50k incidents daily from various product releases)...so those that are seeing it can continue submitting their crashes (in hopes that it does get to us) or they can stop using Talkback for now (to avoid the annoying error).  

As we have found out over the years, that error message is very misleading for a few reasons:
1. It does not always mean it's a proxy related issue.
2. It does not mean that the crash does not get to us (there have been many users that have verified that their crashes show up in queries even when they see the connection error and the client thinks it has not been sent).
3. It sometimes is a result of the Talkback Server being down or the DB having problems (in which case I try to get them back up as soon as possible to allow the incidents to be resent and collected when Talkback automatically tries to resubmit).

Those are a few things to keep in mind about this bug.  An easy workaround is to disable Talkback or make sure to do a custom install and not select that component.  We would prefer you continue to send incidents and if it fails a couple of times, just manually delete it from the queue in the Talkback client window.

We are working hard to do our best to keep things running and there is hope that we will get an update of the software and/or the source to hack on, but for now, we need to accept this bug for what it is and live with it the best we can.  Thanks for understanding.
Assignee: namachi → jay
Whiteboard: See comment #34 for summary → See comment #34 and #70 for summary
I can't get any connection to Talkback servers, too!

I don't have a proxyserver, so my settings are correctly.
I also reinstalled firefox, but talkback still gets no connection.
I tried another computer, but same problem.

I don't have installed any software-firewall.

Please fix that trouble with talkback! 
this known bug still exists.  winXP pro 32bit.  firefox 1.5.0.1.  "The Agent is unable to connect to the server. Please check your Proxy settings or try again later."  not using proxy.  won't connect ever.  have router.  won't send even when starting talkback from components folder.  would be good if there was a way to manually send this info in email somehow.  does talkback create a file somewhere that can be emailed?
> does talkback create a file somewhere that can be emailed?

Yes it creates files:

on my computer, it is: 
C:\Dokumente und Einstellungen\admin.ANDI\Anwendungsdaten\Talkback\MozillaOrg
There, it creates folders for every crash.

But I don't know if you can email that data anywhere... 
*** Bug 213105 has been marked as a duplicate of this bug. ***
Moving over from Bug 213105. I don't know if this is still relevant, but thought it may be.
 ------- Comment #5 From Dan Mellem  2004-07-11 14:40 PST  [reply] -------

I can confirm that this still occurs in 1.7.0 and 1.8a1+ (a2-2004052009) on
Win2000 and WinXP. A packet trace shows that Talkback is connecting and
transferring the data but the server stops ACK'ing the packets after 35 seconds
of transfer. It works fine on a fast link but a congested or slow link (e.g.,
dialup) doesn't work.


*** Bug 330592 has been marked as a duplicate of this bug. ***
(In reply to comment #75)
> Moving over from Bug 213105. I don't know if this is still relevant, but
> thought it may be.
>  ------- Comment #5 From Dan Mellem  2004-07-11 14:40 PST  [reply] -------
> I can confirm that this still occurs in 1.7.0 and 1.8a1+ (a2-2004052009) on
> Win2000 and WinXP. A packet trace shows that Talkback is connecting and
> transferring the data but the server stops ACK'ing the packets after 35 seconds
> of transfer. It works fine on a fast link but a congested or slow link (e.g.,
> dialup) doesn't work.

I have Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 and a direct connection over the internet (DSL)  Talkback began failing for me on Mar 29, 2006.  The last time it worked successfully was Mar 5,2006.
(In reply to comment #25)
> 5. Post the email address or unique comment you provided for the crash incident
> in this bug.

Hey.

I submitted in the last days 10 to 20 crash-reports about Thunderbird-trunk and dont know if anyone has arrived.
Can somebody have a look to the database and can tell me if everything is allright ??? The e-mail-address I used to was slim(AT)lV-crew.org .
Can you please send me an mail to mozilla.bugzilla(AT)lV-crew.org ??? (Please no comment to this bug cause I'm really busy now and bug-comments are filltered out to an subfolder ...)
Some sugestions: Whey not giving the user the chance to search self the database for his e-mail-addi via the public-talkback-page? I think it would be also funny to see how much crash-reports I send in so far ...)

Thx in advance.

slim
Slim, I don't see any of your reports in talback...
(In reply to comment #78)

> I submitted in the last days 10 to 20 crash-reports about Thunderbird-trunk 
> and dont know if anyone has arrived.
> Can somebody have a look to the database and can tell me if everything is
> allright ??? 

You can do this yourself too:

http://talkback-public.mozilla.org/search/start.jsp
http://talkback-public.mozilla.org/reports/thunderbird/

> Some sugestions: Whey not giving the user the chance to search self the
> database for his e-mail-addi via the public-talkback-page?

"If you submit your email address, it will be kept private (only Mozilla will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.
TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch"
Mozilla QA Community:Talkback:FAQ
http://wiki.mozilla.org/Mozilla_QA_Community:Talkback:FAQ
*** Bug 331044 has been marked as a duplicate of this bug. ***
I never got Talkback to work properly on my current installation. Had a few crashes over the last few months, and none of the reports could be uploaded. I don't have a proxy or firewall, checked all the software that might be causing issues, but to no avail :-(
"Airbag to be added to Mozilla applications
Talkback, a crash information reporting tool by SupportSoft, bundled with Firefox and Thunderbird will be replaced with Airbag, a similar open source application. (...)"
http://mozillalinks.org/wp/2006/09/airbag-to-be-added-to-mozilla-applications/

Going open source is the start of fixing all of the problems.
*** Bug 351364 has been marked as a duplicate of this bug. ***
*** Bug 333125 has been marked as a duplicate of this bug. ***
*** Bug 305680 has been marked as a duplicate of this bug. ***
I also cannot connect.  This is on XP after Firefox 2.0 install.
Jay, can we WONTFIX this since we're not going to fix it?
Update and recap (for those not aware of Mozilla's plan to replace Talkback):
----------------------------------------------------------------------------

- Breakpad is going to replace Talkback starting with Firefox 3 (starting with alpha 4) and in other Mozilla products
- Breakpad is open-source so problems and bugs (like this bug 210251) will not stop Mozilla products like it was regarding Talkback because "Talkback is licensed to us to use in it's current state...we do not have access the source code to fix bugs, add features, etc."
Breakpad is an open-source crash reporting software:
http://code.google.com/p/google-breakpad/
- Socorro will be the new database for checking about reporting crash incidents:
http://crash-stats.mozilla.com/

More links and info:
http://wiki.mozilla.org/Breakpad
http://kb.mozillazine.org/Breakpad
Whiteboard: See comment #34 and #70 for summary → See comments 34 & 70; Future: comment 89
Sam:  Feel free to mark any open Talkback bugs as WONTFIX or INVALID (depending on how valid the issue is).  I think that will help us look at current issues with Talkback (WONTFIX bugs) and find ways to improve Breakpad in the future... or confirm that some issues are not valid for whatever reason (INVALID bugs).  Make sense?

Gerard:  Thanks for the great posts in this bug!  I hope anyone watching this bug gets involved with the Breakpad and Socorro projects so that we can work together to make the new crash reporting system better.
Resolving as WONTFIX. Given the move to Breakpad (see comment 89), we aren't going to fix this in Talkback. If you see this issue in Breakpad, please file a new bug with details.
Status: NEW → RESOLVED
Closed: 21 years ago → 17 years ago
Resolution: --- → WONTFIX
Assignee: jay → nobody
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: