User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 My first 2 reports through talkback worked, now my 3rd report will not connect. Tried for 3 days] Reproducible: Always Steps to Reproduce: 1. send in report 2. 3. Actual Results: unable to connect. Error reports please check proxy settings. Did not setup for proxy use. Set 'don use automatic proxy settings'. Did not help. Tried conection after many reboots over 3 days Expected Results: ability to send in reports

talkback.netscape.com has shown up instead of talkback5.netscape.com Now working

1.3a likes to want to talk to talkback5. That server appears to be unreachable. Is there a status page for that server or someway to get talkback to use another talkback server?

may have a been a temporary issue as I also had this issue for 1 day using 20030122 build. Does it now work fine for you ?

I am dropping talkback because of I have yet to see any resolution of talkback issues and no reference to any status pages for the servers to alert users.

Galen: We were switching one of our Talkback servers to a new machine last week...and that might have been the reason you were unable to submit your Talkback incidents. Have you tried again recently? Also, are you using a broadband connection or dialup?

I still can't submit Talkback data with build 20030125 (Win2k) and 2003012522 on Linux, I've got 9 TB IDs to submit. I've got broadband access, also tried at work, same issue; might be the SQL worm from this WE that made AOLTW people to filter very connection from outside ?

Can you try it again? Just start talkback.exe (for Windows) and try to send them.

Any updates on this problem? Have people tried with recent builds to submit Talkback reports?

I just tried to send a crash with 2003022408, but could not. Confirming.

Andrew: Are you connecting through dialup or broadband? Have you tried to manually send the incident by clicking the button in the Talkback UI? Galen: Regarding your comment #1. You couldn't have possibly sent your crash incident through talkback.netscape.com. That server is for internal Netscape users and is behind the firewall. Any external crashes are collected by talkback5.netscape.com. So even if the Talkback progress dialog might be switching between both of those servers, talkback5 is really the only server you will be talking to. I am going to try to send incidents from home tonight and see if they go through. I have had no problem sending crashes here at work (but as I said earlier, my crashes are collected by talkback.netscape.com behind the company firewall).

Oh...I forgot that this was a Windows 98 bug. I'll try with my Windows 98 machine at home tonight and report back. Everyone having problems here is using Windows 98, correct?

Jay, yes, I'm using Windows 98. I'm on a broadband connection (DSL). No firewall or proxy server. I tried to resend it as you describe, but it failed in the same way.

Win98 bug? May I suggest that it be mentioned in the known issues. Yes I am using win98. Yes TB did report connecting to talkback.netscape.com

This should block 1.3.

I was able to send incidents successfully from home using a Windows 98 machine. I have a 144K IDSL connection through a Linksys router using DHCP. I was not using any VPN software and tested with MozillaTrunk build 2003022408. NOTE: The first incident what was sent did indeed show talkback.netscape.com as the server it was contacting. The second incident showed talkback5.netscape.com. I need to verify which on of those servers are actually getting my crashes.

Ok, after digging through my ethereal capture logs, I figured out that although the Talkback progress dialog says you're connecting to talkback.netscape.com, it automatically redirects to talkback5.netscape.com before your incident is actually sent in. After some more testing, I also experienced some problems submitting incidents earlier today with my Windows 98 machine. For a short period of time between 2:15 and 3pm I was unable to send any crashes I submitted. However, around 3pm all incidents that were in queue and any new crashes were being sent just fine. I wonder if we are facing some sort of load issue during certain times of the day?

well I've tried on several builds over weeks at many different times of day. All dead.

Not sure if it makes any difference, but Galen, are you using Windows 98 Second Edition? My machine was a Win98 SE.

Speaking for myself, I've been using Win 98SE.

using win98 SP1 with all updates. I will try ethereal

After discussing this problem with Shiva, I have come to the understanding that external users are able to submit incidents to either talkback or talkback5. That is why some people see different servers in the progress dialog. In terms of a workaround, I think I might have found one. At least for me...when I had a list of crashes in queue, all I had to do was delete the oldest incident that was waiting to be sent and try to send the next one manually. When I did this last night, all my incidents went through ok. For those that still have a long list of incidents waiting to send...could you try this and report back? Thanks.

would be good to get fixed but not going to block 1.3 for this.

Just now I was able to send two Talkback reports. Maybe it is now working? Or maybe it's sporadic?

We are actively fixing the Talkback submission problem. Please try next few more days and give us more feedback. For now, I am going to leave this bug to avoid reporting duplicate bugs.

Bugs 60968, 167536, and 189702 seem to all be the same. People have been having this problem for over two years, and still no resolution. Contrary to what I said in a previous message, the problem does seem to be with connecting. I installed a firewall and watched what was going on, and it never did successfully make a connection (despite maxing out my modem's upstream bandwith the entire time...what on earth is it doing?). If I copy the talkback data and take it into work, it goes through with no problem the first time I try it, every time. My work connection is faster but much more restricted, so that's surprising. Perhaps this wasn't written with modem users in mind. Perhaps the upstream bandwith maxing out shows there is some flaw in the code, such as it has an unrealistic timeout for connecting and keeps retrying and retrying, never really giving it a chance to respond. As I've said before, once in a blue moon it does work, so the capability is there. This problem has been there for years, and I bet it's affecting a LOT of people (how many bother to go into Bugzilla and complain? Most probably just turn it off). I also know that it's not being taken seriously enough to get fixed. You have three identical bugs, and nobody's even noticed that. That shows how seriously it's taken. Oh, and all three are still marked as "NEW" even though one is over two years old. We've asked for this to get fixed. I've asked for an alternative method of sending these (email or uploading) if that can't be done. I guess it's just time to say if you don't care, then we don't care...time to turn this feature off.

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

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

tbid 19157165,19156892 were not accepted in the client even though the same incident was recorded twice in the db tbid=19139461,19139635 were not accepted in the client even though the same incident was recorded twice in the db. use a 56k dialup over sera.

adt: need info. Shiva, is this still a problem? If so, are you getting no data from win 98 users? Are you getting significantly less talkback data versus downloads as compared to milestones before this problem was reported? Thanks.

Talkback data sending problem independent of the Platform. This problems is occuring due to connection issues. We have actively solved many scenarios in sending data. We are investigating few more connection type issues.

adt: nsbeta1-

I am still having trouble with talkback. Mozilla rarely crashes for me since I tend to use major releases. But most or every time it does crash I have trouble. The last time it happened is described <a href='http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c28'>here</a> and <a href='http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c29'>here</a>. Well, Mozilla crashed yesterday, so I again have a talkback incident that I can't submit. I click on "send queued incidents" and then watch my 'bytes sent' go up by 107000 each occasion, taking 30-60 seconds before popping up an error message "The agent is unable to connect to the server. Please check your proxy settings or try again later." I have a dial-up account with Freeserve, a major European ISP. I am not knowledgable about proxies (so it would be nice if the <a href='http://www.mozilla.org/quality/qfa.html'>talkback documentation</a> didn't assume otherwise), but I believe Freeserve offers an optional web cache (www-cache.freeserve.com) while also allowing 'direct' Internet access without any interference by proxies. So I think these settings should work for me: no HTTP proxy, no SOCKS proxy, yes ignore automatic proxy configuration settings ... but I have also tried some other permutations of proxy settings without greater success. I'm on Windows 2000 with Mozilla 1.4 (i.e. 20030624). It might well be unrelated, but it appears that I can shut off my Internet connection by trying too hard to submit an incident. I connected to Freeserve and started trying to submit this incident. The first four attempts each resulted in the sending of 107000 bytes. The fifth attempt was only about 40000. After this, webpages would not load (e.g. "bugzilla.mozilla.org could not be found. Please check the name and try again" or "The operation timed out when attempting to contact www.bbc.co.uk"). Then a couple of minutes later the connection closed by itself. (On that occasion my IP address was 217.135.133.118 in case anyone has access to server logs.) When the same thing happened last night it only took three attempts before I was cut off. The phenomenon reminds me of some occasions when I have tried to send large email attachments via Freeserve and got cut off. (At the time I speculated it might be an anti-spam measure.) I'm willing to try things at this end to help diagnose the problem. Suggestions?

There are 3 or so bug reports that look like they match mine. I picked this one because it has the most recent activity via comments. ... When letting TalkBack do its thing after restarting Mozilla after one of its infrequent crashes, I get: --------------------------- Netscape Quality Feedback Agent --------------------------- The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later. --------------------------- OK --------------------------- This happens after my modem's send and receive LEDs blink back and forth for about a minute. So Talkback has obviously connected with someone/something. I diddle with all possible option setting in TalkBack, same thing. I try turning off my firewall (ZoneAlarm), same thing. I do a clean boot, start only TalkBack, same thing. I try several times over a day or two, same thing. I'm running Windows 2000 SP4, Mozilla 1.4, dial up 56k modem. The same thing happened when I was using Win 2k SP3 and Mozilla 1.1. The same thing happened when I was using Windows 98se and Netscape 4.7x. (This never-ending TalkBack story also spanned multiple motherboards, processors, and a more than one external modem.) (do you detect a pattern?) In the past I just turned off TalkBack after it was caught in a never-ending loop of failed connections. (It got turned back on again with each upgrade of Netscape/Mozilla -- then the cycle repeated. I kept thinking "they" would surely hear about and fix this problem by the next release.) Now I decide to make a bug report and it looks like this has been reported many times from different environments over a long period of time. I may not be reporting anything new, but it is important to note: o this is a real problem o it happens on many machines o it spans several versions of Mozilla/Netscape o it's not getting fixed I'm not mad, but I do believe it leaves a very bad taste in people's mouths to have a crash that can't get reported (remember they don't have any idea that it might be getting reported, they just see what is on the screen.) I will be glad to help engineers get a better handle on this, but I don't have any idea what more to tell them at this time. WRITE TO ME and I'll send whatever/do whatever will help you. Michael Carr

(In reply to comment #33) I'm running into the exact same problem as Michael Carr (comment #33). I've *never* been able to send a TalkBack crash report. I *always* get the "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later." error. I've tried everything Michael has tried. Windows XP Mozilla 1.8a (currently, but has occured on me since 1.2 and Win98) Dialup No proxy server Earthlink ISP Almost my entire time of using Mozilla, I've just ignored Talkback and disabled it because of this problem. I figured it was something that just doesn't work and they just haven't taken out yet. Now with the new push for all platforms to have this "feature", I figured I'd actually spend more than a couple of hours trying to get this to work. Kevin Nehls

I've timed my talkback submissions while watching a packet trace, and it looks like talkback starts a 30-second timer when it starts sending its submission. If after 30 seconds, it hasn't received a response from the server, it aborts the upload and pops up the generic "proxy error" dialog, even if it's still sending the report!! My trace shows it takes about 35 seconds to upload the 105k compressed report (consistent with a 24k modem rate). Talkback was either never tested with modem users, or mozilla is sending *huge* tracebacks compared to Netscape 4. Is there any way to raise the timeout from 30 seconds to 1 minute or more (maybe hexediting talkback.exe)?

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).

Just verifying... There have been a couple of reports in bug 210251 since the last post here. I am still seeing the problem, having just installed Firefox 1.0PR. And as documented in http://bugzilla.mozilla.org/attachment.cgi?id=154095&action=view, each time the agent tries, CPU usage goes to 100%. There should be an entry from 10:15 p.m. EDT beginning with "Upon loading page,". Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 Dell Dimension 4100 (933 MHz), WinXP Pro SP1, modem connection, no proxy.

(In reply to comment #34) I've upgraded to broadband and no longer have this problem. I was able to successfully send a crash/error report from Thunderbird without problems. Kevin

In reply to comment #35, I took some readings while watching the agent send. This is the usual timeline: 00:00 Agent starts automatically. CPU pegs 100%. 00:30 Dialog box closes. CPU idle. Data transmission continues. 00:75 Data transmission ceases after sending about 220KB, receiving ~9K. My throughput is about 50.6K. Broadband is *not* an option. <rant> Does anyone care about this bug? Nearly four years have passed since Bug 60968 was opened 2000-11-22, and the logs from that one, this one, Bug 167536 and Bug 210251 are full of observations, suggestions, and requests for workarounds or alternative solutions for auto-reporting bugs. Comment #33 in this bug, posted a year ago, and http://bugzilla.mozilla.org/show_bug.cgi?id=60968#c48 from 18 months ago, are cogent summaries of the situation and requests for action. Please, either fix it, or stop shipping it with Mozilla Firefox 1.0 Preview Release, which has now surpassed 1,000,000 downloads. </rant> I am tempted to label this Critical, but I will leave that to someone with more authority.

Just another confirmation: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10 - Win98 SE (I think there's a pattern here) - 56k dialup - No proxies (as far as I know of. Not sure what my ISP is doing behind the curtains) - Never succesfully submitted a talkback from this machine (often tried).

(In reply to comment #36) > 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. Today I saw talkback connecting, seemed to be successful, but I got an error message. As the fastfind server wasn´t busy, there was only one file waiting, I just looked for the file number of that file, and then the preceding one, and found my report. I tried to resend it, but seems the server doesn´t accept duplicate reports, so I got same errormessage again. I already had successfully transmitted two reports, and got that bug on the third one. 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). I don´t recommend the email address, as you can´t search for this. You only can search for text in the comment field, or the URL field, besides searching for Talkback ID or Stack Signature. See http://talkback-public.mozilla.org/talkback/fastfind.jsp > 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.

On Nov 1, Firefox informed me of an update to Talkback, so I installed it per the directions, closed FF and restarted. I then recreated my favorite crash-inducing bug (bug # still unknown to me), whereupon Talkback initiated. I dutifully filled out the form and watched as Talkback began its usual sequence of Peg-The-CPU then Transmit-For-Another-Half-Minute-Or-So-With-CPU-Idle then Give-Up-And-Wait-Five-Minutes then Repeat. I let the thing retry all night, and now, almost 24 hours later, it has yet to succeed on the client end. At least I know that the report did make it. It is ID=1665908. http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=1665908 So I guess I will consider this closed when A) At a minimum, the client end sends a complete report successfully B) And ideally NOT peg the CPU for 30 seconds while doing that. If that must be a separate bug, that's OK. Talkback software: Build date 2004-10-01@10:15AM; File version 2.2.0.0 (2.2.unofficial). Mozilla Software: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Machine: WinXP SP2, 933 MHz Pentium 3, 384 MB RAM.

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

Just another confirmation from the latest version of Mozilla Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 - Win98 SE - 56k dialup - I'm don't have a proxy. I've tried 2 different dial-up ISPes in case something my normal one does was blocking talkback) - I'm not using a firewall The sending status referes to talkback.mozilla.org. However if I use netstat, it shows mothra.mozilla.org - netstat also shows multiple connections/connection attempts.

Here's some information about my connection as reported by http://www.broadband-help.com/cm_diagnose.asp Network IP 84.71.70.29 [WHOIS] Host Name Host name not found (0) Proxy Proxied HTTP? Yes Proxy IP 195.92.67.74 [WHOIS] Proxy Name(Raw) 1.1 webcacheH10 (NetCache NetApp/5.5R3D3) Proxy Name(R-DNS) webcacheH10a.cache.pol.co.uk I am using the ISP "Freeserve" at the moment and although I do not have a proxy configured on my computer, it appears that "Freeserve" are re-directing my connections through one. p.s. With "Freeserve" as the ISP. The failure mode is slightly different. I tend to only get one line shown by netstat. The talkback "sending status" pop-up's status starts with "connecting", changes to "sending", then changes to "receiving". These changes take under a second; the status then remains as "receiving" with very little/no data appearing to be exchanged for approx 30 secs before the error message "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later." is displayed. Netstat reports the connection is in the "Established" state whilst the talkback "sending status" pop-up is reporting "receiving". It changes to "Fin wait 2" when the error is displayed. i.e This failure mode appears to match that initially reported in another bug I've now found on talkback sending https://bugzilla.mozilla.org/show_bug.cgi?id=265815 This is different from the failure experianced in comment #35 in this bug. Are there multiple different ways that Talkback fails?

Here's some information about my connection as reported by http://www.broadband-help.com/cm_diagnose.asp When I'm using my other dial-up ISP Network IP 80.47.220.50 [WHOIS] Host Name dial-80-47-220-50.th.lond.access.as9105.com Proxy Proxied HTTP? No Proxy IP n/a Proxy Name(Raw) Proxy Name(R-DNS) An invalid IP Address was passed. Resolution cannot be performed.

We have experienced an outage yesterday for few hours due to Talkback dependency systems. Talkback Server is working. If you still have problems in sending the incident please re-open the bug. In general, you should be able to send incidents within few minutes of occurance. Sometimes due to volume and other dependency issues it might take longer time to send the incident.