Closed Bug 200702 Opened 21 years ago Closed 21 years ago

Links not displayed on page brought up by clicking on "Current Radar" link

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bie, Assigned: asa)

References

(
URL
)

Details

(Keywords: qawanted, regression) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030404 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030404 Chimera/0.7+

The "Current Radar" link displays a weather map with a black border at the
bottom.  The border should contain a set of links (Help, Animate, Close, ...)
which are displayed when the page is opened in Safari, Netscape, Explorer, etc.
The problem is present in Mozilla 1.4a as well.

Reproducible: Always

Steps to Reproduce:
1.open http://www.atmos.uiuc.edu/weather/index.php
2.click on Current Radar
3.

Actual Results:  
no links shown in border below map

Expected Results:  
links to Halp, Animate, Close, ...  should appear.
Using FizzillaMach/2003040103, the Current Radar link spawns a new window
showing two frames. The top frame shows the radar image, and the bottom frame
shows prodempty.htm which is, you guessed it, empty. However, pressing command+r
to reload this FRAMESET results in prodctrl2.htm being shown, though the
FRAMESET source still refers to prodempty.htm.

Using Camino/2003040307, pressing reload does not display prodctrl2.htm.

Puzzling.
This is apparently a regression between Mozilla 1.3 and 1.4a, but it may just be
luck that it worked in 1.3.  The navigation frame is supposed to be loaded by a
JS routine that runs from the map frame's <body onload>.  In Mozilla 1.4a, the
navigation frame does not load when the document is first opened, but if the
document is reloaded, the navigation frame loads as expected.

A better URL for testing:
http://www.atmos.uiuc.edu/weather/tree/viewer.pl?launch/nicerad .

The problem appears to be that one frame is trying to load a document into
another frame with JavaScript, but if the original document specified by the
frameset has not yet been loaded into the target frame, the correct behavior is
unclear.

See also http://www.mentovai.com/tmp/mozilla-200702/ which is a distilled
version of the problem.  It provides a "tryagain" button that lets you try
loading the "proper" frame at will.

Recommend reassign to Browser.

Mark
Of interest, when the document in the static frame (frame1) unsuccessfully attempts to set the document in frame2 onload, the following shows up in console.log (launch /Applications/Utilities/Console.app):

yyyy-mm-dd hh:mm:ss.u Camino[pid] JS error: parent.frame2 has no properties

Mark
I'm seeing this same regression between 1.3.1RC2/OS X and trunk 2003042508/OS X.
Its also this problem on 2003042208/wink2k

I'm not seeing any javascript errors in mozilla's js console.

Changing products & platform accordingly
Assignee: saari → asa
Component: General → Browser-General
Keywords: qawanted, regression
OS: MacOS X → All
Product: Camino → Browser
QA Contact: winnie → asa
Hardware: Macintosh → All
Version: unspecified → Trunk
*** Bug 204819 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529 
(Build 2003052905; Mozilla 1.4 RC 1):  The 'links' are now displayed properly in
this build. The 'current radar' now functions as it should.  This build appears
to have fixed this problem.  
Works for me: Current, Next, Previous, Help, Archive, Animate, Print, Close
Windows buttons all visible.  Can animate and watch moving images.

Mozilla 1.4
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529
indeed... WFM OS X Camino & Moz 08-08-0x.. resolving as such
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.