Cert-o-matic Frames not displaying correctly

NEW
Unassigned

Status

P3
normal
18 years ago
4 years ago

People

(Reporter: junruh, Unassigned)

Tracking

({helpwanted})

Future
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: JavaScipt help wanted)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
1.) Visit the above URL with 4.7 to see how the page should look.
2.) Visit the above URL with Seamonkey.
What is expected: Text input windows, radio buttons and drop-down menus in the 
right frame.
What I see: The right frame is blank. On Mac, both frames are blank. Win98, 
Linux and Mac 9/28 branch builds.

Comment 1

18 years ago
I'm pretty sure that this page relies on the <LAYER> tag which is not supported
in Mozilla.  This is not a bug in mozilla.  This bug belongs in the evangelism
component where hopefully we will convince the site to discard nonstandard DHTML
in favor of a better way.  In general is is not a good idea to post bugs to
Bugzilla which have as their only steps to reproduce visiting a website that is
not accessible to the majority of Bugzilla users.  If you could reduce this page
to a simple testcase and attach that to the bug it would be very helpful.
Assignee: asa → blakeross
Component: Browser-General → Evangelism
QA Contact: doronr → zach

Comment 2

18 years ago
-> evangelism@telocity.com for my evangelism bugs.

removing the now-depreciated evangelism-related keywords.

setting platform to All.
Assignee: blakeross → evangelism
Hardware: PC → All
Assignee: evangelism → wtc
Component: Evangelism → Tools
Product: Browser → NSS
Target Milestone: --- → Future
Version: other → 3.1
I'm taking this away from "evangelism", and sending it to the 
manager of the NSS group, where (IMO) it belongs.  

This bug is really simple.  NSS source includes the source
to a little test cert server program named "Cert-O-Matic".
It is really intended just for internal use by the NSS team,
but its source is part of the open source on mozilla.

That server consists of a set of programs that run as CGIs
in an ordinary web server.  Those CGI programs use some 
html web pages that do indeed contain <LAYER> tags.

Someday, we should stop using layer tags.  

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

18 years ago
Not my department to QA for. Kicking it over to sonmi@netscape.com. I 
can't get to this URL
QA Contact: zach → sonmi

Comment 5

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → tools
Assignee: wtchang → nobody
Status: ASSIGNED → NEW
Created attachment 238868 [details] [diff] [review]
patch, fixes display but loses variables (checked in on trunk)

If you apply this patch to nss/cmd/certcgi/index.html in your workarea,
then you can use your browser to visit that page, and you will see how
cert-o-matic is supposed to appear in the browser.  You'll see the 
links on the left, and that they change the contents of the frames on
the right.  But you'll also see that if you fill in some data on any of
the right-side frames, and then switch frames on the right, and switch
back, that all the contents were lost.  

So, this patch restores the appearance of cert-o-matic in mozilla 
browsers, but doesn't work properly.  

part of the index.html file is supposed to capture the contents of the 
variables in the right frame before switching to another right frame,
and then restore the variables used on the right side.  I haven't been
able to get that to work, haven't been able to find the Javascript 
syntax for accessing the variables in the other iframe.  Maybe it can't
be done for security reasons.  I haven't spent any time researching it.

Alexei, if this interests you, please feel free to take a stab at it.
I should add that the problem with the transfer of variable values is 
mostly in the javascript functions save_cur_page and reload_form.

I should add that the code in stnd_ext_form.html that handles the 
subject alt name, issuer alt name, and nme constraints extensions is
also not working properly.  Any attempt to add a name to any of those
extrensions fails.  I didn't want to tackle that until the main problem
with saving and restore right-frame variables was fixed.
Comment on attachment 238868 [details] [diff] [review]
patch, fixes display but loses variables (checked in on trunk)

Patchj committed on trunk.
Checking in index.html; new revision: 1.4; previous revision: 1.3

result appears correct in mozilla browsers, but the JavaScript for
the left frame is unable to access the values of the variables in
the right frame.  

JavaScript help wanted!
Attachment #238868 - Attachment description: patch, fixes display but loses variables → patch, fixes display but loses variables (checked in on trunk)
Keywords: helpwanted
Whiteboard: JavaScipt help wanted
You need to log in before you can comment on or make changes to this bug.