Closed Bug 60099 Opened 24 years ago Closed 15 years ago

Quality Feedback Agent failed to engage. w2k ntfs readonly

Categories

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

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: timeless, Assigned: jcarpenter0524)

References

Details

(Keywords: arch, helpwanted)

Netscape6rtm windows2000advanced server w/ terminal services. installed as 
administrator onto an ntfs partition w/ only generic read permissions for all 
users.

User Zach runs netscape6.
Zach does something stupid [this usually crashes the web browser]:

1. Opens Sidebar (actually uncollapse).
2. Selects Bookmarks (actually it was selected by default, Zach just started 
Netscape6 for the first time).
3. Drags the top entry (Mozilla Project)
between
Webtools and Community.
4. This shouldn't be a problem, except for the fact that.
5. Both are [direct] children of Mozilla Project
Result:
drwatson runs.

why?
Mortal Zach has no idea, but it sure takes a long time to do nothing. Netscape6 
doesn't die instantly, it just sits there, and his mouse is still attached to 
that bookmark. Netscape6 isn't responding, and Netscape.com doesn't get a 
talkback report.

Eventually netscape6 vanishes. Zach doesn't know anything about talkback, and 
since there was no console, Zach didn't know it wouldn't run.

If you want to sit in Zach's chair for an hour, please contact me on irc. 
Zach's session is usually available via vnc.
--> janc@netscape.com
Assignee: namachi → janc

*** This bug has been marked as a duplicate of 72664 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Excuse me?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
your right. this is not a dupe.  but its also something that
we are unlikely going to be able to fix.

talkback executables are hardwired to write to the master.ini
in the installation directory.  shiva might know if there 
is someway we can redirect the writing of the file to 
another location, but I think its unlikely.  the talkback
code is frozen at this point, so its just likely that
we will have to live without being able to get data
from this kind of configuration set up.
yeah :(
Status: REOPENED → NEW
Keywords: arch, helpwanted
Whiteboard: Odds we can fix this: very poor
I have successfully gotten fullsoft/talkback to launch and save data in an 
arbitrary directory. There seems to be nothing we can do about the talkback 
executable and saved data being relative to fullsoft.dll, but it is possible to 
move fullsoft to some other directory and launch it there by hacking 
ns/fullsoft/src/win/spiwrap.c

In order for talkback to work talkback.* also needs to be moved next to 
fullsoft.dll. Master.ini needs to be there too, unless we switch from 
FCInitialize() to FCInitializeWithManifest() in which case we could leave 
master.ini where it is.

The equivalent wrapper code for unix is ns/fullsoft/src/unix/nubglue.cpp. 
Although we could clearly change the directory talkback.so is loaded from I can 
only assume the same relative directory relationships would hold.

The Mac glue code appears to be delivered in binary form so we're stuck there, 
but we're probably OK for the time being until OS X takes off.

For my test I just hacked in a hardcoded directory. To do this for real we'd 
have to change the FCInitialize() API to accept a directory (or perhaps switch 
to FCInitializeWithManifest() and use that directory). Our QFA component would 
have to check for file existence in some writable spot, and the very first time 
copy the libraries into the user profile (or perhaps the OS $HOME).

Which brings up a related point -- QFA isn't launched until after the profile 
is selected so it doesn't/can't catch really early crashes. For sure it 
wouldn't catch problems in the Profile Manager itself, though it may be early 
enough after profile selection to catch crashing problems in the profile 
itself. That would be important because I've seen many cases in the Netscape6 
newsgroups where creating a new profile helps people get around a crash -- are 
we getting data on those crashes or not?

We may wish to explicitly launch qfa early in startup (nsAppRunner.cpp) rather 
than use the dynamic "appshell component" mechanism. I believe Alecf created a 
replacement mechanism for embedding to use which may fire earlier, maybe not. 
If we launch qfa prior to profile selection then putting fullsoft and its data 
in the profile isn't an option, but we could still find something relative to 
wherever the "Application Registry" ends up.

It'd be easier if we could get a change in the talkback library itself, of 
course.
I'm having a problem myself with the talk back agent. My browser has crashed
three times already, however whenever I go to send the report it states that the
agent is unable to connect to the server. I have tried restarting my connecting
and still the agent won't send the reports.

There are now two reports and I'm not sure as what to do. I have Windows ME and
this is the first ever occurence that I've had with the Mozilla browser, the
crashes two of which happened on websites, the other happened after
unsuccesfully installing JAVA but that report sadly wasn't able to be saved.
The talkback server is down, ETA for a fix 10pm PST. Try sending them again
tomorrow.
Whiteboard: Odds we can fix this: very poor
Blocks: 65754
Now that Talkback has been replaced with Breakpad, can this bug be closed?
Product: Core → Core Graveyard
Yes.  Breakpad doesn't work on win2k either, but that's bug 382124.
Status: NEW → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.