Bug 4888 – Missing support for many window.frameElement properties (Frame size calculation at SoftwarePlanner broken)

• Component: Frames
• Status: RESOLVED INVALID

[Alexey Proskuryakov]

A project management suite called Software Planner is not correctly rendered by current versions of 
Safari. It used to work correctly with WebKit up to 312, but doesn't work (in different ways) with 412.2 
or ToT. Steps to reproduce:

1. Go to <http://www.pragmaticsw.com/SoftwarePlanner.asp>
2. Click on "Try Sample Database"
3. Click "Logon"

Results: 
- (stock 1.3 and earlier): works correctly
- (stock 2.0, 2.0.1 or 1.3.1): the contents briefly renders correctly, then the left frame expands, 
completely covering the right one
- (ToT): the contents briefly renders correctly, then the left frame expands, taking half 
of the page.

Firefox works with this site OK.

[Patrick Geiller]

Created attachment 3831 [details]
Test case

Wait 2 seconds to see the right pane disappear. 

Software Planner miscomputes frameset.cols, replacing a correct '230, *' with
'NaN,  *'. Firefox ignores it, so should Safari.

[Alexey Proskuryakov]

(In reply to comment #1)

Thank you!

There's still a slight weirdness - Safari 1.2.4 fails on this test case, but not on the actual SoftwarePlanner 
page. Could there be a second problem, which makes frameset.cols get miscomputed on newer versions 
of WebKit? I'll leave the NeedsReduction keyword there for now...

[Patrick Geiller]

I don't have Safari 1.2.4 so I can't test. But you can :) Save the page with firefox, then open psDALeft.htm 
and comment out line 486

window.frameElement.parentElement.cols = (window.frameElement.width + 10) + ', *';

This removes the bug. Both Safari & Firefox show window.frameElement.width as undefined. Maybe Safari 
1.2.4 has a correct value ?

[Alexey Proskuryakov]

(In reply to comment #3)
Safari 1.2.4 simply did't get to execute this code at all (I have replaced it with a plain alert("test"), and got 
nothing). I don't understand why, but it seems totally unrelated.

Another mistery: on ToT, the test case works OK (I have checked, window.frameElement.width is still 
undefined) - but the actual page resizes the frame to 50%...

[Patrick Geiller]

> Safari 1.2.4 simply did't get to execute this code at all

Maybe some Javascript fails before it. Does the JS console show anything ? 

> Another mistery: on ToT, the test case works OK (I have checked, window.frameElement.width is still 
> undefined) - but the actual page resizes the frame to 50%...

I just tried the test case in ToT and at first glance it does work. However, the JS in the test case is NOT 
executed. Add an alert() and nothing pops up ! So, copy

javascript:alert(document.getElementsByTagName('FRAMESET')[0].cols = 'NaN, *')

in the address bar and launch it to see the frames resized like in the actual page.

[Alexey Proskuryakov]

Created attachment 3845 [details]
Incomplete Test

[Alexey Proskuryakov]

(In reply to comment #5)

I see... To work in ToT, the test needs to be modified a bit.

However, it looks like Firefox also doesn't ignore NaN! After 2 seconds, the right frame expands to 100%. 
There must be something else in the actual page that makes it work in Firefox...

[Alexey Proskuryakov]

There are probably at least two issues here: window.frameElement.width is not undefined in WinIE - it's 
230, so the +10 part does work as intended.

[Alexey Proskuryakov]

Created attachment 4032 [details]
frameElement tests

[Alexey Proskuryakov]

Ok, so Firefox renders the page fine because it doesn't handle 
window.frameElement.parentElement.cols at all: 

try {
    window.frameElement.parentElement.cols;
} catch (e) {
    alert('Exception: ' + e.description);
}

prints 'Exception: undefined'. This leaves us with a single WebKit issue - lack of support for 
window.frameElement.width (and some other frame properties supported by WinIE, see the attached 
test case for details).

[Alexey Proskuryakov]

frameElement.width was implemented in bug 6402, so the actual problem is fixed. It doesn't look like keeping this bug is doing us any good, closing.