37886 - NS Admin screens w/frames not displaying properly

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Curtis Williams]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win98; I)
BuildID:    2000050111

When accessing the Netscape Administration Server screens for admin server 
version 3.5, the Mozilla browser improperly displays the frames.  Buttons are 
missing and only text is being displayed.  I have attached screen shots from NS 
4.72 and Mozilla for comparison.

Reproducible: Always
Steps to Reproduce:
1. Login to NS Admin v3.5 server screens
2.
3.

Comment 1

[Curtis Williams]

Attachment: NS 4.72 correct image

Comment 2

[Curtis Williams]

Attachment: Mozilla incorrect image

Comment 3

[R.K.Aa.]

same/similar server as in bug 36389 ?

Comment 4

[Curtis Williams]

Yes, I think so.  I actually had the same problem with the Messaging Server 
admin screens, but hadn't reported it.  This is the first time I've had a 
problem with the admin screens.  If you'd like I can submit a screen capture of 
the correct and incorrect Messaging Server screens as well as the same 
Enterprise screens mentioned in 36389.

Comment 5

[R.K.Aa.]

In bug 36389 [e-mail] requests a testcase.
The bug may be known from - or not - but that's hard to decide without a clue as
to what triggers it.

Can you save a page (showing the bug) as HTML source?
Then see if it looks the same when loading it locally from disk.

If the bug is visible then too, it would be fine if you add it as an attachment
here.

Select "create a new attachment" in the bug-form. You can browse your disk by
clicking the browse-button on that form, to get path to the saved page
auto-filled in before sending.
Also indicate in the form what type of attachment it is (html), and add a brief
description (or it won't sumbit).

Comment 6

[Curtis Williams]

Well, it seems that the admin screen wants to display properly with no changes 
having been made to my PC, but the Messaging Server frames are still not 
displaying.

Here is what I did:

Loaded the MS frames in NMS 4.72 - all OK.
Loaded the MS frames in mozilla - not OK.
File | Save Page As from inside mozilla.
Loaded that file into mozilla - not OK.
Loaded that file into NMS 4.72 - not OK.

I have attached a correct image from NMS 4.72 and an incorrect one from Mozilla. 
Interestingly enough, when you load the file from disk into NMS 4.72 you get the 
incorrect display also, which seems to indicate the some of the HTML is being 
dropped by mozilla since the HTML source was saved with mozilla.

This is kind of confusing.  Feel free to call 270-745-5251 to speak in person if 
necessary.

Comment 7

[Curtis Williams]

Attachment: NMS 4.72 Messaging Server frames

Comment 8

[Curtis Williams]

Attachment: Mozilla Message Server "frames"

Comment 9

[Curtis Williams]

Attachment: Mozilla incorrect HTML

Comment 10

[Curtis Williams]

Attachment: NMS 4.72 Messaging Server frames - ignore first one

Comment 11

[Curtis Williams]

Attachment: Try this for HTML source

Comment 12

[Curtis Williams]

Just tried something else:

Opened the frames page in NMS 4.72 and did a Save As and NOT a Save Frame As and 
tried to load what was saved in mozilla with the same incorrect results.  I then 
opened a new NMS 4.72 browser window and tried to open the saved HTML file with 
the same incorrect results, so it appears as though the Save function is not 
saving all of the HTML.  It would appear the HTML source I've attached is 
suspect and can't be relied on.

Comment 13

[R.K.Aa.]

Doesn't seem the error is in that code. Given a random doctype header it turned
up fairly OK. Didn't look at the screenshots till now however, they woke
memories: I actually have root/admin access on an Origin200/Netscape Messaging
Server. So much for daft helpers.. I'll try make a testcase this weekend.

[e-mail]: Thanks for your efforts.

Comment 14

[Eric Pollmann]

> It would appear the HTML source I've attached is 
> suspect and can't be relied on.

One method I use to save the html source of a page when Save As doesn't work is 
this. Say for example the url is http://netscape.com

1) Type this into the url bar:

view-source:http://netscape.com

A view-source window will pop up with the source of the page.

2) Select all of the text, then paste it into a text file.

This will give you the source of the page before any javascript contained in the 
page is executed. I don't know if this will be helpful in your particular case, 
but it might help...  Thanks for looking in to this!

Comment 15

[R.K.Aa.]

just in case:
ctrl+a selects all text in view-source window (much quicker than using mouse)
ctrl+c to copy selection to clipboard

Comment 16

[Curtis Williams]

This is all I get with the view-source: added in front of the URL for accessing 
the Messaging Server configuration screens:


<HEAD><TITLE>Netscape Messaging Server
</TITLE>
<SCRIPT language=JavaScript>

var optloaded=0;
var helpwin=0;

</SCRIPT>
</HEAD>
<frameset rows="84,*" marginwidth=0>
<frame src="index?tabs" scrolling=no  marginwidth=0 marginheight=0 name="tabs">
<frame src="index?category" scrolling=no  marginwidth=0 marginheight=0 
name="category">
</frameset>

Comment 17

[R.K.Aa.]

Netscape Messaging Server 3.6:
Attaching the html in the main frame.

Comment 18

[R.K.Aa.]

Attachment: NS Messenger Server 3.6 main frame.

Comment 19

[Eric Pollmann]

*** Bug 36389 has been marked as a duplicate of this bug. ***

Comment 20

[Asa Dotzler [:asa]]

setting this bug to New

Comment 21

[Curtis Williams]

As a possible addition to this bug (but it could be a new one totally separate), 
all of the recent builds, say in the past week or two weeks tops, no longer seem 
to want to connect to a 3.x admin server.

When I try to reference  http://fsmail.wku.edu:1802/  I should get an 
authentication dialogue box to give me access to the NS 3.x Admin server.  
Instead I get absolutely nothing - no box to authenticate, no HTML error page.  
Whatever was previously on the screen continues to display.

I use this admin server on a daily basis with NS 4.x, so I know the admin server 
is working properly.

Let me know if I should log this as a separate bug....

Comment 22

[Eric Pollmann]

*** Bug 27366 has been marked as a duplicate of this bug. ***

Comment 23

[Eric Pollmann]

Curtis, your's is a separate problem, the WWW-Authenticate line must be 
capitalized properly (Basic auth type has to be capitalized).  I got nothing 
when using the headers your server sent back:

<-------- Received from server --------
HTTP/1.0 401 Unauthorized
Server: Netscape-Administrator/3.5
Date: Fri, 16 Jun 2000 22:03:53 GMT
WWW-authenticate: basic realm="Netscape Administration"
Content-length: 223
Content-type: text/html

<HTML><HEAD><TITLE>Unauthorized</TITLE></HEAD>
<BODY><H1>Unauthorized</H1>
Proper authorization is required for this area. Either your browser does not per
form authorization, or your authorization has failed.
</BODY></HTML>
<-------- End transaction -------->

But when I changed this line:

WWW-authenticate: basic realm="Netscape Administration"

To:

WWW-authenticate: Basic realm="Netscape Administration"

I got the dialog, this is bad - I'll open a new bug on the Necko folks...

Comment 24

[Eric Pollmann]

I've entered bug 42881 to cover the capitalization issue.

Comment 25

[Eric Pollmann]

Curtis, the source you provided for the main page is very useful, thanks.  I'll 
probably need to get a copy of Enterprise/Messaging Server going myself though 
and look at this more closely.  I'll try to get my hands on one (Geez, I work 
here, so it shouldn't be that hard, right?)

Comment 26

[Eric Pollmann]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 27

[David Marston]

I've been doing a bit of investigating on this, and the problem seems to be that
the name of the bottom left frame in the window is options, which mozilla sees
as an [object JSOptions].  If the name of the frame is changed to something else
it is seen as an [object Window], and the problem disappears.

This appears to be similar to <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=37258">bug 37258</a> and <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=33650">bug 33650</a>.

I'm adding a reduced testcase showing this.

Comment 28

[David Marston]

Attachment: Reduced testcase (frameset a.html containing two frames)

Comment 29

[Eric Pollmann]

CC'ing our DOM guru - pretty screwy result for parent.<framename>  I haven't
looked into this one yet, but the reduced test case (zip file) is scary.

Comment 30

[Eric Pollmann]

Brendan, this is not a DOM property - is there a new JS global property
"options" that could be masking named frames like this?  When trying to get the
frame named "options" we get back a [object JSOptions].

Comment 31

[Brendan Eich [:brendan]]

I suck!  I wired up the options object, for controlling JS options such as 
strict and werror, in exactly the wrong way.  And this after going through the 
"must resolve common names lazily to avoid preempting them" drill several times 
in my too-long DOM life.

Patch coming up -- please r= and a= for quick branch checkin.

/be

Comment 32

[Brendan Eich [:brendan]]

One character change to fix this bug for N6 -- rename the property I added to
_options!  Looking for fast r= and a= so I can get this into the trunk and then
[rtm+] it.

/be

Comment 33

[Brendan Eich [:brendan]]

Attachment: proposed fix

Comment 34

[Johnny Stenback (:jst)]

I assume there's no code in mozilla that relies on the current name 'options',
right?

If not, then r=jst.

Comment 35

[Brendan Eich [:brendan]]

No checked in code uses options.  People in the community want it to enable
per-HTML-page strict JS warnings.

/be

Comment 36

[vidur (gone)]

a=vidur. I assume we can leave the name of the corresponding pref as-is.

Comment 37

[Brendan Eich [:brendan]]

Yes, no need for pref renaming.

Fix is in the trunk.

This is another fix for backward compatibility, a one-character patch to boot. 
PDT, how about it?

/be

Comment 38

[Jim Roskind]

Rtm double plus to landing on branch asap.  This helps us work with iPlanet,
which is significant (and as noted... patch is pretty small).

Comment 39

[Brendan Eich [:brendan]]

You can take this one char change, but you can't take a change to correct Braden
McDaniel's misspelled name?

/be

Comment 40

[Brendan Eich [:brendan]]

Fixed in branch as well as trunk.

/be

Comment 41

[Chris Petersen]

Not sure how to verify this fix.

Comment 42

[Chris Petersen]

Brendan,

I need help to verify this issue.

Comment 43

[Brendan Eich [:brendan]]

Make a frameset page where one of the frames is named "options", that contains a
form containing an input with name="textInput", and the other frame containing
some JS that addresses top.options.document.forms[0].textInput.value = "hi" or
some such from an onclick handler for a button.  Wait till everything loads,
then click the button.  You should see "hi" in the text input with the fix. 
Without, you should see top.options.document has no properties in the JS console
(or similar error).

/be

Comment 44

[David Marston]

If it helps I can tell you that the latest nightly builds now work with the NS 
Admin Server frames.

Comment 45

[Chris Petersen]

Fixed in the Oct 19th builds.

Comment 46

[Chris Petersen]

Old issue that was verified awhile ago but not marked.