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

VERIFIED FIXED in mozilla1.9beta5

Status

()

Core
XPConnect
P2
normal
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Fernando Piera, Assigned: jst)

Tracking

({regression})

Trunk
mozilla1.9beta5
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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
(Reporter)

Updated

11 years ago
Version: unspecified → Trunk

Comment 1

11 years ago
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)

Comment 3

11 years ago
Fallout from bug 397850 perhaps?

Comment 4

11 years ago
The ~10 sec was for a small test msg, for a message with a ~20K attachment to remains open for one minute.

Comment 5

11 years ago
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

Comment 6

11 years ago
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

Comment 7

11 years ago
> The regression window for this problem is 2008-01-15-04 -- 2008-01-16-04.
Forgot: this is with Firefox on Linux

Comment 9

11 years ago
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.

Comment 10

11 years ago
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
(Reporter)

Comment 12

11 years ago
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.

Comment 13

11 years ago
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)

Updated

11 years ago
Flags: blocking1.9?
Duplicate of this bug: 413313

Comment 15

11 years ago
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

Comment 17

11 years ago
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
 

Comment 18

11 years ago
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?

Comment 20

11 years ago
After sending, no error at all in console.

Comment 21

11 years ago
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
...
Created attachment 298989 [details] [diff] [review]
Proposed fix

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)
(Reporter)

Comment 23

11 years ago
I wonder if this bug is related with  one that prevents printing emails from the inbox. 

Comment 24

11 years ago
Using 298989 patch still produce this bug; sending mail dialog and print preview dialog keep opened.
(Assignee)

Comment 25

11 years ago
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+

Comment 26

11 years ago
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 27

11 years ago
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+

Updated

11 years ago
Keywords: checkin-needed

Updated

11 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This was actually checked in yesterday... Does it still reproduce in tonight's nightlies?
Keywords: checkin-needed

Comment 31

11 years ago
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.

Comment 33

11 years ago
> 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.

Comment 35

11 years ago
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.
Duplicate of this bug: 415576

Comment 39

11 years ago
When i move my mouse on the 'close' button the message dialog disappears right away.

Comment 40

11 years ago
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 ?

Comment 41

11 years ago
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.
(Reporter)

Comment 42

11 years ago
To me this is a different bug as it begin at a different time.  I will open a new bug

Comment 43

11 years ago
(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

Comment 44

11 years ago
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.

Updated

11 years ago
Flags: tracking1.9+ → blocking1.9+
(Assignee)

Comment 45

10 years ago
Created attachment 307144 [details] [diff] [review]
Fix.

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+
(Assignee)

Comment 47

10 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 48

10 years ago
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!

Updated

10 years ago
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

Updated

10 years ago
Duplicate of this bug: 424425
You need to log in before you can comment on or make changes to this bug.