76795 - chromeless browser windows should not get redirected content

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Scott MacGregor]

chromeless pop up windows seem to somehow be getting redirected content. I don't
think this is correct.

For instance, if I go to the url listed above, and click on one of the baseball
games, I get a little radio popup which streams the baseball game to me. 

If I then close all my other browser windows, then click on an http link in the
mail window it gets redirected to this little chromeless popup window.

Comment 1

[Scott MacGregor]

triaging. This bug is pretty annoying to me since I use this radio popup all the
time.

Comment 2

[Marek Z. Jeziorek]

changing TM to 0.9.2 per PDT meeting (you can check the fix into 0.9.1 trunk
until Friday, 18/May/01 or after the 0.9.2 is open)

Comment 3

[Scott MacGregor]

I have a band aid fix for nsBrowserContentListener.js which I'm going to post
right now. 

Our goal is to make sure we don't register browser windows which are chromeless
with the uriloader as an active window. When we register with the uriloader we
are ssaying, this window wants to accept redirected content that other windows
can't handle. 

The patch fixes the following problems:
1) View source a mail message. Make sure you don't have any browser windows
open. leave the view source window up, now click on a http link in a mail
message. Before this fix we would have loaded it in your view source window. Now
we'll create a full fledged chrome browser window.

2) Go to www.netscape.com or some other website which uses popups. Keep
re-loading the page until you get a popup. Startup mail. Close the browser
window. Leave the popup window alone. Click on an http link in mail. You should
see the html content get loaded in the popup. with this fix we'll create a new
window. 

3) Go to the url i listed in this bug on major league baseball.com. You can
listen to a live baseball game. It uses a popup window to show the real audio
controls for the game. Clicking on a http link in mail can cause you to load in
this chromeless popup. 

In all of these cases it's still possible to reproduce these problems with
browser windows open when you click on links in mail. But it's easier to
reproduce if you don't have any browser windows open.

Note: Just because these chromeless popups aren't registering with the uriloader
anymore doesn't mean they can't receive redirected content. If the popup has a
window target name, we'll still find it when content is directed to that window
target. 

cc'ing alecf for review on this hack to nsBrowserInstance. He may tell me he
wants this encapsulated in a global routine in navigator.js. something like
IsBrowserChromeless? of window.chromeless.....

Comment 4

[Scott MacGregor]

Attachment: possible fix to nsBrowserContentListener.js

Comment 5

[Scott MacGregor]

alec, have you had a chance to look at this yet? thanks!

Comment 6

[Alec Flett]

excellant. sr=alecf

Comment 7

[scottputterman]

adding PDT+.  Please check this into the trunk as soon as possible.

Comment 8

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 9

[Scott MacGregor]

fixed into the tip. 

Comment 10

[lchiang]

doron - since you're the qa contact, will you be able to verify this?  If so,
pls reassign the QA contact to me.  Thanks.

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

I can verify that scenarios 1 & 2 are now fixed, but MLB.com is now charging for
that content (see URL above).  But, #3 is really #2 anyway ;-)

Mac OS 9.1 - 2001-07-23-08 
RedHat 7.1 - 2001-07-23-08
Windows 2K - 2001-07-23-03

trunkverified.

Is this going on the branch? If so, let me know and I'll take care of that
verification soon.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

If this missed the branch, then I'm able to mark this verified (since I've done
the legwork on the trunk already).  Please let me know, thanks.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

verified fixed (see criteria and build dates above).