269831 - Radar loop plays onall other tabs on Mozilla, locks up on Firefox downloaded on 11/7

Status: RESOLVED DUPLICATE of bug 162134

(Core Graveyard :: Java: OJI, defect)

Description

[Jordan Fairman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11
Build Identifier: Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910

The loops at http://www.srh.noaa.gov/radar/loop/DS.p19r0/si.ktbw.shtml play on top of any other tab 
on a Mozilla version which I downloaded on 11/10/04. Bug #1717189 is about these loops but the last 
comments I saw regarding that bug are dated April 2003 and it appears that the bug might be 
considered resolved. 
When I tried these loops on firefox it just locked up the browser and gave me the spinning beachball. 
After a couple minutes I did a forced quit.

Reproducible: Always
Steps to Reproduce:
1. For Mozilla: load http://www.srh.noaa.gov/radar/loop/DS.p19r0/si.ktbw.shtml
2. Open another tab. The loop plays on the new tab no matter what page I load.
3.


Expected Results:  
It shouldn't show the radar loop box on every tab

I'm not a web pro but this is a pretty basic problem. Netscape rumming in OS 9.2 sometimes had 
problems with these NWS radar loops and some of the other experimental pages they were trying so 
sometimes I wondered if the NWS guys were writing bad web pages.
I'm running OS 10.3.6 on a Titanium Powerbook G4
I hope I have not wasted your time and mine.
Thanks for your effort.

Comment 1

[Kenneth Herron]

I believe you mean bug 171789.

Comment 2

[xolaware.llc]

this may or may not be the same bug, but i found similar behavior in firefox
[Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0] using a different java applet (using Safari confirms this behavior
does not cause their tabbed browsing to be screwed up in the same way, which
leads me to believe this is a problem accepting output from the java runtime and
not properly checking which tab is frontmost when displaying the output).

the URL in question is:

http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/JavaSSOP.html

1] start at a different URL
2] open the above URL in a new tab
3] click in the java tab "SkySearch"
4] enter a location in the location menu (i chose "San Diego")
5] hit the "Search" button
6] go back to the original tab and continue browsing

expected results:  only when going back to the tab with the java applet running
should output from that tab be displayed

actual results:  even when browsing in a different tab, the java output gets
displayed when it should not.

Comment 3

[Daniel Veditz [:dveditz] out until Nov 10]

The tab-drawing issue sounds like bug 162134. Is that what this report is
basically about? If we dupe that part is the lock-up covered elsewhere as well?

Comment 4

[Pete Zha]

mass reassign to Alfred

Comment 5

[Wayne Mery (:wsmwk)]

Perhaps Jordon is gone, gone.

Could the lock up be bug 171789?

I agree the tab issue is dupe of bug 162134


(In reply to comment #2)
> http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/JavaSSOP.html
> 
> 1] start at a different URL
> 2] open the above URL in a new tab
> 3] click in the java tab "SkySearch"
> 4] enter a location in the location menu (i chose "San Diego")
> 5] hit the "Search" button
> 6] go back to the original tab and continue browsing

just a datapoint - windows wfm  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a

Comment 6

[Wayne Mery (:wsmwk)]

*** This bug has been marked as a duplicate of 162134 ***