Les Gasser Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141125180439

Steps to reproduce:

TBird V 31.3.0 "up to date" (not sure why versions in the choice box go up to 37?)

I "Send"-ed a message, then opened another message and began saving an
attachment.




Actual results:

I was in the Save Attachment dialog, when the message I was sending "in the background" got a Send Message Error due to a temporary internet issue getting to the SMTP server.

This situation - both Save Attachment and Send Message Error boxes open and awaiting responses - is a deadlock. I can't "OK" the error box, can't save the attachment or cancel it, and can't even quit TBird. I have to force quit TBird with Activity Monitor and restart it.

(Hard to reproduce because of uncertainty raising the Send Message Error - depends on external internet connectivity. You can't just shut off your wifi to set up a test condition because TBird detects the offline condition and diverts to "Send Later")



Expected results:

Expected: no deadlock; e.g., some precedence for the response boxes (possibly with primary precedence to TBird Quit?), and certainly not a completely un-resolvable deadlock. 

Found *possibly* related bugs 530608 and 476541 BUT a) these are old and b) 476541 is a Browser bug, not Thunderbird.

	Wayne Mery (:wsmwk)
	Comment 1 • 9 years ago

Hi Les. Are you still seeing this problem with version 38?

If you are, then this is indeed bug 530608 (old or not, it still is alive and well)

	Les Gasser Reporter
	Comment 2 • 9 years ago

Wayne, thanks for your work on this and your query. I haven't checked to see if it's still there, and probably won't have time to do so in the near future because of the somewhat stochastic nature of the bug.

After reading the other referenced bug reports including 530608, 647408, 838213, and 847179, it looks like there may be a relationship to this one. Whether these are the *same* bug would depend on whether the underlying causes and mechanisms the same, e.g.  whether the same conflict/deadlock mechanisms are at play in all these cases.

If raising one (modal) window can block action on buttons in other windows, and if that blocking action uses the same mechanisms for all window combinations, (same shared variable(s) and access functions for example) then I'd say yes, these are dupes.

However, if different sets of windows block each other using different lock variables and/or different functions, then these bugs aren't dupes in my view because they would require different fixes in code. Fixing one of them wouldn't impact the others.

- Les Gasser

	Les Gasser Reporter
	Comment 3 • 9 years ago

One more thing - so it seems there is more "needed info": someone has to look at the code and see whether the window blocking mechanisms are the same, and what's the cause of the deadlock, for each of the combinations reported in these different bug reports.  

- Les

	Wayne Mery (:wsmwk)
	Comment 4 • 9 years ago

I'm quite certain that bug 530608 and it's friends are the basis for your issue. It's a reasonably well understood architectural issue that must be changed, but no one seems to have the motivation to address it.