140192 - steltor.com - calendar app uses IE4/NN4 JS

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[David]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020425
BuildID:    2002042510

Using our company web calendaring application, selecting the Add Event icon brings you to a form for inputting subject, date, time, etc for the meeting. In NS4.79, IE5 and IE6, everything renders properly and the form is usable (see WebCalNS4_79.gif attachment). In Mozilla 0.99, , only the New Meeting title and the bar containing the Create, Cancel, and Help buttons appear (see WebCalMozilla2002042510.gif attachment). Prior version of Mozilla rendered just the scroll bars of the text input areas - not the labels or the text input areas themselves. Sorry, it's an Intranet app and you can't get to the page in question without having an ID on our system. It's a product called Corporate Time for the Web.

Reproducible: Always
Steps to Reproduce:
See description.

Actual Results:  See attached WebCalMozilla2002042510.gif

Expected Results:  WebCalNS4_79.gif

The earlier OS/2 version I have at home (sorry, forgot that build and I'm not at home right now) had problems rendering the page, too.

Comment 1

[David]

Attachment: What the page should look like.

Comment 2

[David]

Attachment: How Mozilla renders the page in question.

Comment 3

[Christopher Hoess (gone)]

->Form Controls

Comment 4

[Boris Zbarsky [:bzbarsky]]

David, any chance of saving the page as "web page, complete" and attaching a
zipped-up version of all the files that get saved to this bug?

Comment 5

[David]

OK, will try the save as web page complete and attach a zip file, when I get back to work tomorrow.

Comment 6

[David]

As requested, I'm attaching a Zipped up "save as, complete" version of the problem page.

Comment 7

[David]

Attachment: HTML & graphics of prb page from "Save As, complete"

Comment 8

[Boris Zbarsky [:bzbarsky]]

The code basically does the following:

isNS = document.layers ? 1 : 0;
isIE = document.all ? 1 : 0;


After that it assumes that if isNS is false isIE must be true (and document.all
is defined) and vice versa.  Since neither of these non-standard objects is
defined in Mozilla, the code quickly throws a JS error.

Now we get to the fun part.. the stylesheer has:

    .optionLayerClass{position:absolute; top:0; left:0; visibility:hidden}
    .repeatFreqClass{position:absolute; top:0; left:0; visibility:hidden}

So the clever designer has all the content hidden and then unhides it with
javascript (never mind the fact that the user may have JS turned off).  In this
case, the unhiding does not happen, because the script hits the syntax error
mentioned above and stops execution....

To evangelism; unfortunately the only thing that can be done here is to get the
page's author to update to the JS to work with the numerous standards compliant
browsers out there using the standard DOM (the same codepath would work for
IE5/5.5/6, Opera, Konqueror, Mozilla, etc).

Comment 9

[David]

re Comment #8 - Not thrilled at the solution (trying to get the author of the page to correct it to work with standards compliant browsers). It works fine in IE5, 5.5, 6, Netscape 4.7x. I guess IE6 still supports the non-standard IE way of doing things? Oh, well, guess I can't use that app with Mozilla.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yeah; if IE6 were to nor support it, thousands of sites that sniff for IE and
use document.all would fail; MS obviously does not want that....

Could you possibly provide contact information for the person who would have to
make changes to the page?  That way an evangelist can contact him/her and offer
to help to make the page work in Mozilla...

Comment 11

[David]

re Comment #10, only information I can provide is http://www.steltor.com/content/index.cfm?fuseaction=support, try their tech support contact.

Comment 12

[David]

also re Comment #10: The vendor also does a Linux version, I wonder if it has the same problem? Presuming that such a version might be used by more people who use Konqueror.

Comment 13

[Boris Zbarsky [:bzbarsky]]

If I recall correctly konqueror implements document.all, so _some_ sites like
this work in Konqueror....

Apart from that, I suspect that Konqueror is not on this vendor's radar....  :(

Comment 14

[David]

FYI, I reported this to the vendor's support staff. They forwarded it on to their project team as an enhancement request. I also included Boris' explanation of the problem (see comment #8) to help them get started. I hope it gets addressed.

Comment 15

[Bob Clary [:bc] (inactive)]

David, any updates from the vendor?

Comment 16

[Bob Clary [:bc] (inactive)]

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

Comment 17

[David]

I checked with our Steltor administrator. They are currently testing version 3.1. We checked using the most recent Mozilla she has (0.9.2.1 for Linux) and the problem is gone. I also checked it in Mozilla 1.1 for Linux (Gecko/20020913) and it works fine. I think this qualifies as FIXED! 8-)