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.

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

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)

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.....

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

excellant. sr=alecf

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

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

fixed into the tip.

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

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.

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.

verified fixed (see criteria and build dates above).