356703 - Browsers associated with closed tabs aren't loading a blank document

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: 2006-10-14-13, Windows XP SeaMonkey trunk.

Probably fallout from bug 350416 or friends.

Summary: Flash-derived audio doesn't stop when closing its tab.

Caveat: I searched, and couldn't find a duplicate of this.  Additionally, this DOES NOT occur in Firefox trunk (Minefield).

Steps to Reproduce:

1. Load a page which contains Flash-based audio, such as Pandora.com or YouTube.com
2. Open a new tab.
3. Now, close the tab with the Flash audio.

Expected Results:

Audio stops.

Actual Results:

Audio keeps playing.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

So, just as I suspected: setting browser.tabs.undoclose.depth to 0 fixes this...

Comment 2

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Backing out https://bugzilla.mozilla.org/attachment.cgi?id=240756&action=edit has no effect.  Why is the hidden browser not actually navigating away?  Use DOMI to change the linkedbrowser in one of your non-closed tabs to point to the closed browser, and note that it's still on the old page.

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

stephend, this isn't on branch because it crashes gecko.

Comment 4

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: this causes blank documents to load

The key lines would be:
-            oldBrowser.stop();
+//            oldBrowser.stop();

I'm pretty sure the first patch chunk is irrelevant as it's for a different bug.  I don't know why removing the .stop() before didn't seem to work.

The interesting thing is that even with .stop(), the blank tab's title changes, but the page content stays there.  I saw biesi saying something about clearing the current page once the next load starts - is it possible that the title changed but the "load" didn't start yet for document-clearing purposes?

Comment 5

[[e-mail]]

Sorry, I thought the LOAD_FLAGS_FROM_EXTERNAL would suffice to evict the page.
We can't allow the blank document to load because of bug 354927.

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #5)
> Sorry, I thought the LOAD_FLAGS_FROM_EXTERNAL would suffice to evict the page.
> We can't allow the blank document to load because of bug 354927.
> 

Would a new load flag work? ("Don't prompt for SSL"?)

Comment 7

[[e-mail]]

The SSL dialogs work off the progress notifications.

Comment 8

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: patch

As far as I can tell, this doesn't change the behavior of https://bugzilla.mozilla.org/attachment.cgi?id=200420 - I get an "entering secure" which is immediately followed by a "leaving secure" alert (kinda odd that the leaving secure happens while the entering is still visible though...).

Do we want to add an API for extension authors to add/remove listeners so that they don't go and add a listener, thus regressing bug 313335 when tabs are reopened?

Comment 9

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 245957 [details] [diff] [review]
patch

Let's pretend I had this comment before the secFlags line:
//XXXcst warning: make sure these flags match nsDocShell

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 245957 [details] [diff] [review]
patch

One odd thing I did notice was that doPreview sometimes seemed to fire to show the tooltip, and it was firing at a point where there was no contentWindow, causing that code to throw.  Not sure what to do about that.  (try {} in doPreview?)

Comment 11

[[e-mail]]

Comment on attachment 245957 [details] [diff] [review]
patch

>+            const CiIWP = Components.interfaces.nsIWebProgress;
Please use const nsIWebProgress here. r=me with that fixed.

Comment 12

[jag (Peter Annema)]

Comment on attachment 245957 [details] [diff] [review]
patch

sr=jag with Neil's nit fixed.

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Checking in mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.168; previous revision: 1.167
done

Things that need to be specially verified: bug 313335, undo close of a tab that had an ssl page, ssl warnings on tabs that were previously closed and reopened.

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED with build 2006-11-21-09 of SeaMonkey trunk under Windows XP.

My understanding of comment 13 is:

[22:45] <stephend> if I have netscape.com in one tab, then https://original-oncourse.iu.edu/login/profile/default.asp in another tab
[22:45] <stephend> close the HTTPS tab
[22:45] <stephend> then restore it, I don't get its alert
[22:46] <CTho> stephend: that's the point

If this is wrong, let me know.