Closed Bug 413200 Opened 17 years ago Closed 16 years ago

Progress dialogs do not close (message sent, print, print preview)

Categories

(Core :: XPConnect, defect, P2)

Product:
Core
Component:
XPConnect
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta5

People

(Reporter: fpiera, Assigned: jst)

References

Details

(Keywords: regression)

Attachments

(2 files)

Proposed fix
855 bytes, patch
jst
: review+
jst
: superreview+
damons
: approval1.9+
Details | Diff | Splinter Review
Fix.
416 bytes, patch
mrbkap
: review+
mrbkap
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011910 Minefield/3.0b3pre
Build Identifier: version 3.0a1pre (2008011903)

When sending an email message, the small window explaining that the message has been sent persist open and does not disappear for quite a long time blocking partially the thunderbird application until it disappears. The email message has been sent in any case.

Reproducible: Always

Steps to Reproduce:
1.write an email message
2.push the send button
3.the samill window stating that the email is being sent appears indicating the perccentage of the progress of sending

Actual Results:  
The  small window persists open even after it indicates that the email hast been succesfully sent 100%

Expected Results:  
The small window disappear inmediately after having completed the sending of the email message

This has been happening since nightly update of 20070115
Version: unspecified → Trunk
I've been seeing this too for the last few days. For me it does go away, but the dialog remains open at least ~ 10sec, sometimes much longer.

If the regression window is 2007-01-14 -> 2007-01-15 bug 365751 seems very much like it could be to blame
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-01-14&maxdate=2007-01-15+04%3A00%3A00&cvsroot=%2Fcvsroot
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Summary: When sending an email, the message window mentioning that the message has been sent persist and does not desappear blocking particially thunderbird → When sending an email, the message window mentioning that the message has been sent persist and does not disappear (for at least some time)
Fallout from bug 397850 perhaps?
The ~10 sec was for a small test msg, for a message with a ~20K attachment to remains open for one minute.
are you sure the 2008-01-15 build is busted?  I see a regression between seamonkey builds 2008-01-15-09-trunk and 2008-01-16-09-trunk
I see a similar regression around this time which I think is the same
underlying bug; the Print Preview dialog that says "Processing..." does
not auto-close as it should, it only closes when I hover it.
The regression window for this problem is 2008-01-15-04 -- 2008-01-16-04.
I've verified that bug 397850 is fixed in the 2008-01-15-04 build -
so if the Print Preview problem is the same as you're seeing it cannot
be caused by bug 397850.

That said, I don't see any obvious candidates in this window:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-15+03%3A00&maxdate=2008-01-16+05%3A00&cvsroot=%2Fcvsroot

> The regression window for this problem is 2008-01-15-04 -- 2008-01-16-04.
Forgot: this is with Firefox on Linux
The window never goes away at all for me, after sending an html message.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012003 Thunderbird/3.0a1pre ID:2008012003
If I cancel after some minutes, Zone alarm still shows periodic activity, as though the end on the message was never detected.
Also, although the message was actually sent, no copy of same in the sent folder.

I can confirm it's indeed 2008-01-15 -> 2008-01-16 for linux builds.
Backing out bug 352791 locally fixes the lingering Print Preview dialog.
Blocks: 352791
I have observed that when the dialog box remains open at the time of nightly updating by checking the update box, the thunderbird does not reopen until the dialog bos disappear and sometimes this can be a metter of several minutes independently of the lenght of the message sent.
this also affects the print (not preview) progress dialog.  Probably all of them (I can't think of any others).

It also seems that moving my mouse off the dialog (which blurs the dialog) consistently closes the dialog.  It seems to stay open arbitrarily long if I don't do that.

==> Core
Assignee: nobody → jag
Component: Message Compose Window → XP Toolkit/Widgets
Product: Thunderbird → Core
QA Contact: message-compose → xptoolkit.widgets
Summary: When sending an email, the message window mentioning that the message has been sent persist and does not disappear (for at least some time) → Progress dialogs do not close (message sent, print, print preview)
Flags: blocking1.9?
My build of 2008012110 in Linux and Mac OS X (both Intel and Universal), got this problem too. Hovering the window will close it after 3 seconds.
The patch attached to bug 412598 fixes this issue.
Depends on: 412598
Assignee: jag → nobody
Component: XP Toolkit/Widgets → XPConnect
QA Contact: xptoolkit.widgets → xpconnect
Assignee: nobody → mrbkap
Hmmm..according to the build log here:
http://tinderbox.mozilla.org/Thunderbird/ that patch should have been included in the hourly builds: ID:2008012116 and ID:2008012117
However, for short messages the "sent progress" goes away normally now, but for larger html messages, the window still persists with original symptoms reported here.
Last tried build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012117 Thunderbird/3.0a1pre ID:2008012117
 


Latest build 2008012210 the window still opened forever, even with short messages sending to localhost. I confirm the patch already applied.

Are there any errors in the error console?
After sending, no error at all in console.
Here is debug output after a successful sending a message:

WARNING: empty langgroup: file /mozilla/gfx/thebes/src/gfxFont.cpp, line 902
Trying to position a sizeless window; caller should have called sizeToContent() or sizeTo(). See bug 75649.
nsMsgComposeSendListener: Success on the message send operation!

Message Delivery SUCCEEDED!
nsMsgComposeSendListener: Success on the message send operation!
CopyListener::OnStartCopy()
nsMsgComposeSendListener::OnStartCopy()
CopyListener: SUCCESSFUL ON THE COPY OPERATION!
nsMsgComposeSendListener: Success on the message copy operation!
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 937
WARNING: NS_ENSURE_TRUE(newRoot) failed: file /mozilla/content/base/src/nsRange.cpp, line 619
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805C0002: file /mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 1055
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805C0002: file /mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 314
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805C0002: file /mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 1442

THE CLEANUP ROUTINE FOR nsMsgComposeAndSend() WAS CALLED
###!!! ASSERTION: nsWeakReference not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file nsWeakReference.cpp, line 146
WARNING: empty langgroup: file /mozilla/gfx/thebes/src/gfxFont.cpp, line 902
--WEBSHELL 0xae0b100 == 6
--WEBSHELL 0x9bc7fe0 == 5
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file /mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 767
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file /mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 767

ComposeUnload from XUL
--WEBSHELL 0xaa23388 == 4
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file /mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 767
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file /mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 767
--WEBSHELL 0x9796c00 == 3
--WEBSHELL 0xa830b00 == 2
--WEBSHELL 0x969ebd8 == 1
--DOMWINDOW == 13
--DOMWINDOW == 12
--DOMWINDOW == 11
--DOMWINDOW == 10
--DOMWINDOW == 9
--DOMWINDOW == 8
WARNING: nsExceptionService ignoring thread destruction after shutdown: file /mozilla/xpcom/base/nsExceptionService.cpp, line 191
--DOMWINDOW == 7
--DOMWINDOW == 6
--WEBSHELL 0x9c0c548 == 0
WARNING: not an nsIRDFRemoteDataSource: 'remote != nsnull', file /mozilla/rdf/datasource/src/nsLocalStore.cpp, line 340
WARNING: not an nsIRDFRemoteDataSource: 'remote != nsnull', file /mozilla/rdf/datasource/src/nsLocalStore.cpp, line 340
...
Attached patch Proposed fix — — Splinter Review 
This patch seems to fix a related bug whose cause seems likely to be the same as this. My previous patch assumed that if there was a context pushed that we should use, then it would have running code on it. Because this isn't always the case, not all of the bugs were fixed. This makes us actually look at the context stack before overriding it.
Attachment #298989 - Flags: superreview?(jst)
Attachment #298989 - Flags: review?(jst)
I wonder if this bug is related with  one that prevents printing emails from the inbox. 
Using 298989 patch still produce this bug; sending mail dialog and print preview dialog keep opened.

Comment on attachment 298989 [details] [diff] [review]
Proposed fix

This seems like the right thing to do whether it fixes this bug or not (as isn't clear per the previous comment).
Attachment #298989 - Flags: superreview?(jst)
Attachment #298989 - Flags: superreview+
Attachment #298989 - Flags: review?(jst)
Attachment #298989 - Flags: review+
We all don't believe in screenshots right? But how I tell if no error in console log and debug log produce the same as comment #21. I tried clean build with the patch and still the same.
Comment on attachment 298989 [details] [diff] [review]
Proposed fix

Blake, are you cool to request approval for this patch? It has r+ and sr+ already.
I was planning on checking this in using the fact that the this bug blocks bug 412729 as approval. I'm not going to have a chance to check it in for a few hours, though.
Blocks: 412729
Attachment #298989 - Flags: approval1.9?
Comment on attachment 298989 [details] [diff] [review]
Proposed fix

a1.9+=damons
Attachment #298989 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This was actually checked in yesterday... Does it still reproduce in tonight's nightlies?
Keywords: checkin-needed
I still see this with build 2008-01-29-11
Keywords: checkin-needed
Keywords: checkin-needed
I'll have to build Thunderbird and debug this on the weekend, then.
> I'll have to build Thunderbird and debug this on the weekend, then.

FWIW, this bug does occur in firefox with printing.  The page needs to be big enough that it uses a progress dialog.
Any issues with printing and print dialogs on a 64-bit Linux operating system (even with a 32-bit application) are more likely bug 414314 than this bug.

Issues on 32-bit Linux operating systems and any other operating system are probably this bug.
fyi- I'm having the progress doesn't close on sending email problem on Windows 32bit.
I should have also said all dialog issues not involving printing regardless of OS are NOT bug 414314.

(In reply to comment #33)
> > I'll have to build Thunderbird and debug this on the weekend, then.
> 
> FWIW, this bug does occur in firefox with printing.  The page needs to be big
> enough that it uses a progress dialog.
> 

I only see Firefox printing dialog issues under 64-bit Linux OS and that is bug 414314.  My progress dialog dismisses itself just fine under Windows.

It also dismisses itself correctly under linux if I hack the printer ppd file as suggested in that bug as a workaround.
When i move my mouse on the 'close' button the message dialog disappears right away.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020703 Thunderbird/3.0a1pre ID:2008020703
Progress bar never reaches 100% when saving large attachments.
Same Bug ?

Is this somehow connected to bug 412593? That regressed about the same time and is also about a window that doesn't close although it did before (the mail window in that case).

(In reply to comment #40)
> Progress bar never reaches 100% when saving large attachments.
> Same Bug ?

Probably not, unless that problem has the same regression window.
To me this is a different bug as it begin at a different time.  I will open a new bug
(In reply to comment #42)
> To me this is a different bug as it begin at a different time.  I will open a
> new bug
> 
Indeed the regression range is different.
https://bugzilla.mozilla.org/show_bug.cgi?id=416342#c2


FWIW, I hit this bug running the dom/tests/mochitest/ajax/offline mochitests.  None of the opened windows close on their own (although window.close is called).  If I focus/blur the window, it does close... their failure to close hoses any future test that attempts to do something with focus.
Flags: tracking1.9+ → blocking1.9+
Attached patch Fix. — — Splinter Review 
The problem here was that the outermost nsJSContext::ScriptEvaluated() call came from XPConnect, which doesn't call termination functions on the context in fear that there's still code running on the context that depends on it not happening until the code is done. This makes is so that if XPConnect is the last one to evaluate a script on a context and there's no other JS running on that context, we run the registered termination functions, and thus the window really does close here.
Assignee: mrbkap → jst
Status: NEW → ASSIGNED
Attachment #307144 - Flags: superreview?(mrbkap)
Attachment #307144 - Flags: review?(mrbkap)
Comment on attachment 307144 [details] [diff] [review]
Fix.

Yes, please!
Attachment #307144 - Flags: superreview?(mrbkap)
Attachment #307144 - Flags: superreview+
Attachment #307144 - Flags: review?(mrbkap)
Attachment #307144 - Flags: review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Tested in hourly build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030318 Thunderbird/3.0a1pre ID:2008030318
Verified Fixed Yay!
Flags: in-testsuite?
Verified FIXED using Thunderbird trunk version 3.0a1pre (2008030903) on Linux, Mac OS X (10.4) and Windows Vista.
Status: RESOLVED → VERIFIED
This made it in beta 4, or is it beta 5?
(In reply to comment #50)
> This made it in beta 4, or is it beta 5?

Looks like it missed beta 4 by a few hours -> http://wiki.mozilla.org/Firefox_3.0b4:BuildNotes#Tags, if I'm reading that right.
Makes sense why b4 users are seeing this then :)
Target Milestone: --- → mozilla1.9beta5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: