Closed Bug 200702 Opened 23 years ago Closed 22 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: 22 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.