435986 - Attachments dialog does not correctly recognize all canceling of connect to network file share dialog boxes and hangs up for a long time in some situations

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, defect)

Description

[Alexander Kohr]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: version 3.0a2pre (2008052703)

When composing a message if the last attachments folder was on a un-available (ie. shut off/dead) file server and you click cancel to stop trying to connect to the server, Thunderbird hangs in spinny beach ball for a long time thereafter. Some users force quit the applications thinking it is unrecoverable dead. This has happened to two of my end users.

Reproducible: Always

Steps to Reproduce:
1.	Set up a afp file share (share personal files) on a system that is not an important system. Hereby referred to as fileshare.com.
2.	On a second system (client.com) Set up a new profile in thunderbird to check an email account. 
3.	from client.com in finder from  “Go” menu select  “Connect to Fileshare …” fileshare.com. (I used afp://client.com)
4.	On client.com -Compose a message & click on the attach button and attach a document that is located somewhere on fileshare.com. 
5.	Send the message. 
6.	On client.com disconnect from fileshare.com
7.	Shutdown the system fileshare.com .
8.	Quit & re-launch Thunderbird on client.com.
9.	On client.com compose another message and click on the attach button.


Actual Results:  
A.	It takes forever to bring up the looking up client.com dialog box. (Probably due to os timeout settings. 
B.	However after you click cancel it takes forever (over another minute) for thunderbird to recover and bring up the actual attach File(s) dialog box to Documents folder. The Spin control developer tool claims a total of 143.28 seconds in total from step 9 till end of Actual results B.



Expected Results:  
 Once I clicked the cancel button to not connect to the fileserver that is not available it to next to immediately bring up the attach Files dialog box to some sort of available directory for instance the Documents folder or my home directory or desktop.



a. I did not test with other connection protocols like smb, webdav, smb or ftp
b. If you are on the network and the server is online & your are not mounted and you click the cancel button when the authentication credentials come it the Attach File(s) dialog comes up rather quickly.

c. If you are working offline & the dialog box comes up “Connection failed The server may not exist or is is not operational at this time. Check the server name or IP address and try again” and you click okay the attach file(s) dialog box comes up right away.

I can’t verify this but Because of b& c brining up the dialog box significantly quicker, I suspect that apple might return a different error code number when the file server is being looked up & the users clicks cancel than when B or C occurs. 

At least some form of this occurs in the code base has been going on since at least version 1.0.5 ( the one user was still using that)
 
New user profiles where created with versions 2 & 3 of firefox. 

Workaround wait for grey hair or go into config editor and editing a blank value for mail.compose.attach.dir that causes it not to try to connect to the file share (what I figured out prior to discovering that it actually recovers on it’s own)

Comment 1

[hansen]

I can't find any similar bugs, but could you try beta2 or the latest nightly?

Comment 2

[Alexander Kohr]

To answer Wayne Murray's question he emailed me privately. 
"Alexandar, are still using thunderbird?"

Explicitly, I do not use thunderbird except to debug issues end users are having.  I have done some testing of firefox 3.0.1 today though.

I tried it today using thunderbird 3.0.1 on an intel mac running 10.4.11   "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1" & I had the same issue occur of taking forever to bring up the cancel dialog box & then when I clicked cancel it would take a while for it to then display my documents folder. 

I noticed in the freely available Xcode/developer tools "spin control" application under 10.4.11 Thunderbird-bin would start hanging and then unlike my previous documentation about  a second later afp_mount would start hanging. The afp_mount & Thunderbird.bin would hang for about the same amount of time. . However after clicking the cancel button, the thunderbird-bin would then reset it spin control sample time & hang again for significantly longer then the  initial hang time.

Since this also occurred on an intel mac I have changed the platform from power pc to all. 


I then tried 3.0.1 on a Power PC box running 10.5.8  "Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1"  Spin control only ever shows thunderbird-bin as hanging. After what I speculate is the Time out for attempting to connect to a file share A dialog box Comes up "Connection Failed The server may not exist or it is not operational at this time. Check the server name or IP address and your network connection and try again." I then click the OK button and it quickly defaults to my documents folder.  Of not the afp_mount process did not appear in spin control, If it matters.

Also I think this only affects 10.4.X boxes as 10.5.8 seems to handle things much more gracefully, therefore if I knew how to debug I would probably look at what was being returned by 10.4 that is causing Firefox to hang a second time.

Comment 3

[Nomis101]

If this would be helpfull I can try to reproduce this on my Intel Mac. BUT I don't have an afp file share, I only have a ftp one. Is this Bug specific to afp or will it also work if I attach the file from my ftp share? And I don't run 10.4.11, I run 10.6.2. So does it make sense to test this on 10.6.2?

Comment 4

[Alexander Kohr]

Under 10.4.11 on the intel based mac ftp does not produce the same results, so it is useless for testing.
 
What happens under 10.4.11 with ftp
"It will spin the beach ball for about a minute & even though the ftp server is powered down (so the share will not work) an dialog box entitled "FTP Files System Authentication" will appear containing the text ' Enter your user name and password to access the server at the URL "ftp://ephedra/." You name and password will not be sent securely. '  If I click cancel the attachment window opens quickly If I try to authenticate even though the server is down it hangs." 

I tried connectng to the same mac via afp to see If I could replicate results using one computer & the mac os afp is smart enough to realize that you are connecting back to itself & won't let you do it. So whomever in house is testing this will need access to a 2nd macintosh with Apple File Share Protocol turned on in the sharing preferences pain. You should be able to connect to an afp box via ip at another location if needed. However you will have to coordinate with the system owner turning off & on afp.
 (FYI- you might be able to get away with setting up netatalk under linux box to provide afp services. I have not tried it but I don't see why it would produce different results as the problem occurs when the afp server is no longer on the network. The following link contains some information on setting up netatalk under ubuntu to do time machines backups and up to step 4 should give you an idea of how to set u the files share. steps 4 on should be unnecessary. http://www.kremalicious.com/2008/06/ubuntu-as-mac-file-server-and-time-machine-volume/  )




I have not yet tested this on a 10.6.2 box as for some reason I can't remote control our 10.6 test box which is in another building. I will provide updates once I test it out.

Comment 5

[Alexander Kohr]

After today's testing this problem only seems to occur under mac os X 10.4.X. Whomever does the testing will have to have a mac os X 10.4 box.

Testing under 10.6.2 of thunderbird 3.0.3 with afp & the 2ndary server shut down.

Of note, The 10.6.2 box was okay, my remote control software was just caching the old ip address and not getting the new one.

The Beach ball will spin for about about what seems like a minutes (probably the timeout period for attempting an afp connection) It produces an error message similar to the 10.5.8 error 'Connection failed the server "testafpserver" may not exist or is unavailable at this time. Check the server name or IP address, check your network connection, and then try again.'  When I click the "OK" button it quickly brings up the attach files dialog box set to the users documents folders.

Comment 6

[Nomis101]

(In reply to comment #5)
> After today's testing this problem only seems to occur under mac os X 10.4.X.

Hm OK. But I don't have a Mac with 10.4 anymore, I only use 10.6.2. So it seems I can't help you :( Hopefully you will find somebody with 10.4. But I think its an interesting point that your problem only accours under 10.4.

Comment 7

[Alexander Kohr]

I don't find it that interesting. Things break/change with every os revision. They may have changed how they return the home directory is not available errors to applications. 

I have a feeling that 10.4.X will be cut as an acceptable system prior to somebody with a 10.4 box fixing it.

Comment 8

[Ludovic Hirlimann [:Usul]]

Smokey anybody I could ping in the camino Comunity to test and confirm this on 10.4 ?

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #8)
> Smokey anybody I could ping in the camino Comunity to test and confirm this on
> 10.4 ?

Ludo, Eiichi is our only regular on Bugzilla that's still on 10.4.

Given the setup required here (at least two Macs, one of them running file sharing over AFP), though, you might ask someone from MoCo QA if they could try to reproduce it in their QA lab. Maybe mstange still has a 10.4 box, too; I'm not sure.

(I suspect, as the reporter has alluded, that this isn't a problem on 10.5+ because of the vastly improved "server went AWOL" handling in the OS/Finder starting on 10.5, and, given that, there may be little that can be done on the Gecko end to ameliorate things.)

Comment 10

[Wayne Mery (:wsmwk)]

I suggest this is a known issue with network drives / shares and dupable, unless someone here thinks this is Mac specific

Comment 11

[Alexander Kohr]

@Wayne Mery. 
Which bug are you suggesting this might be a duplicate of?

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to comment #11)
> @Wayne Mery. 
> Which bug are you suggesting this might be a duplicate of?

dupme basically means "I don't know or I don't know right now, but anyone is welcome look for it". 

What I can tell you it's related to a known class of bugs involving files on drives that have become disconnected. A very poor bug query from which you can alter is http://bit.ly/cA6gm7

Comment 13

[Larry]

I just spent too many hours at work trying to sort this problem. I won't bore you with the details. I finally isolated to problem to the prefs.js file for the profile that had the problem (other profiles worked ok). From previous posts I think it may have just not timed out yet but it was taking so long that I gave up waiting for it.

I found a line like
user_pref("mail.compose.attach.dir", "[directory reference]");
where [directory reference] pointed to another computer in the office, one that was off at the time. When I commented out that line and restarted TB3 it worked fine.

I don't know how that line was set  in prefs.js (other people in the office usually use that computer) but it was set on TB3.05. Before I discovered the cause I upgraded to 3.1 and it still hung so I rolled back to TB3.04 and it still hung. Of course both attempts used the sameproblem prefs.js file. Is the problem that it tries to make the connection listed in prefs.js or is the problem  in making that prefs.js entry in the first place?

All this was on Windows XP Pro.

Is this sufficient confirmation?

Comment 14

[Ludovic Hirlimann [:Usul]]

Thanks for the info.

Comment 15

[Wayne Mery (:wsmwk)]

Larry, yes, your issue is probably related to this bug.  Were you able to skim the bug list in comment 12?  http://bit.ly/a49kEO is a much better list (I hope)

If someone ever totally hangs, then you may be seeing bug 482811. (But as described, this bug is not a dup of bug 482811.)

Comment 16

[Larry]

(In reply to comment #15)
> Larry, yes, your issue is probably related to this bug.  Were you able to skim
> the bug list in comment 12?  http://bit.ly/a49kEO is a much better list (I
> hope)
> 
> If someone ever totally hangs, then you may be seeing bug 482811. (But as
> described, this bug is not a dup of bug 482811.)

From a quick look at your list I'd say this is related to or a duplicate of 442908 and 466130. 4666130 is  titled "Thunderbird hang when network share no longer available" but I suspect it is not actually hanging, just taking a very long time to timeout, much longer than I would normally want to wait.

This next time I have this problem (probably meaning that someone else in the office cries Help!) should I tell the boss that it is a known bug and being fixed, or it is just a figment of the staff's collective imagination?

Comment 17

[Alexander Kohr]

Today under Thunderbird 3.1.6 and 10.4.11 I confirmed it was still happening. I then tested using a smb based file share & the same issue occurred (Note : from earlier testing ftp mounted shares for some reason don't have the same problem.)

Case 442908 is currently specifically for windows boxes accessing an SMB share whereas my case it is a mac accessing an AFP or SMB share. They could be the same but the scope of 442908 would need to be expanded to all platforms & if possible the title should include afp shares as well and in the notes a mention that on Macintoshes ftp is not affected.  

466130  Also  would need's it's scope expanded but is not very specific as to what they mean by File share. My guess is that one is a dup of 442908

Comment 18

[Alexander Kohr]

Also of note this case has 10 users associated with it yet 442908 only has three so maybe the dup should go the other way even thought he other is older?

Comment 19

[Wayne Mery (:wsmwk)]

(In reply to Alexander Kohr from comment #17)
> Today under Thunderbird 3.1.6 and 10.4.11 I confirmed it was still
> happening. I then tested using a smb based file share & the same issue
> occurred (Note : from earlier testing ftp mounted shares for some reason
> don't have the same problem.)

Case 442908 is currently specifically for
> windows boxes accessing an SMB share whereas my case it is a mac accessing
> an AFP or SMB share. They could be the same but the scope of 442908 would
> need to be expanded to all platforms & 

unclear whether the issue would be OS specific or protocol specific - but I would think the later - so bug 442908 could be dupe


> if possible the title should include
> afp shares 

note there is a recent report about AFP in Bug 700397 - Firefox 5-7 on Mac OS X network drives (AFP) is slow to the point of being unusable