Closed Bug 16963 Opened 25 years ago Closed 23 years ago

missing JS handled pop-down menus

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED WONTFIX
mozilla0.9.1

People

(Reporter: gemma, Assigned: harishd)

References

()

Details

Attachments

(1 file)

With Communicator, rolling over the menu at the top will have the sub-menu pops
down, but M10 doesn't handle that
Assignee: mccabe → trudelle
Component: Javascript Engine → XP Toolkit/Widgets
Guessing XP Toolkit.  Any clues there?
Assignee: trudelle → rickg
Component: XP Toolkit/Widgets → HTML Form Controls
Those menus are all part of the HTML content, using CSS absolute positioning,
nothing to do with XPToolkit.  reassigning to rickg for triage.
Assignee: rickg → trudelle
Peter, why isn't this javascript response in XUL? CSS involves style/layout, but
not event response.
Assignee: trudelle → hyatt
I guess I don't understand how this involves XPToolkit, even if the reponse
should be done using XUL.  reassigning to hyatt for triage.
Assignee: hyatt → rickg
This is referring to HTML-implemented "popup menus".  XUL has nothing to do with
this.
Assignee: rickg → rods
Rods -- please take a look
changed to M14
changing to M15
Target Milestone: M14 → M15
Updating QA Contact.
QA Contact: cbegle → ckritzer
Component: HTML Form Controls → Javascript Engine
mass-move to M16
Target Milestone: M15 → M16
moving to M18
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
I need to take a closer look at this. Marking M16 for now until I know more
Target Milestone: M18 → M16
If you run mozilla with the console open, you'll get the following error when
you mouse over one of the top images (ie "products", "solutions", etc):

JavaScript error:
http://www.sgi.com/ line 102: menus[menunumber] has no properties
Attached file Simplified example
Here is what is going on:

<STYLE TYPE='text/css'>
#menu5 {position: absolute; left: 533px; top: 24px; z-index: 106; visibility: 
hidden; width: 77px;}
</STYLE>

...

<div id=menu5>
...
</div>

When you apply style that includes positioning to a div tag in 4.x it turns it 
into a "layer" object. You refer to it directly by id (for example 
window.dicument.menu5) Then you can set the visibility directly on the object 
like:

window.document.menu5.visibility = 'hidden';

This all works.

When this very example is run in Mozilla, it can't find the element using the 
window.document.menu5 because the id is "menu5" not the name. Then, even if you 
found the object using getElementById, setting the visibility directly on the 
obj doesn't work.

In the attached example their is a boolean "doNav" which lets you test it for 
Nav using nav code, or you can set it to false to try it out in Mozilla with 
standard DOM attrs.

This is a backward compatibility issue.

reassigning, I'll with you jst.
Assignee: rods → jst
Status: ASSIGNED → NEW
Keywords: 4xp, nsbeta3
M16 has been out for a while now, these bugs target milestones need to be 
updated.
There are numerous severe problems on the SGI page, both HTML problems and DOM
problems. The worst problem is that the markup for the popups is *after* the
html end tag (</HTML>) in the file and because of that the elements that make up
the popup menus don't end up in the document.

As for the DOM problems, the site needs to be changed to not rely on
non-standard 4.x DOM extensions, for instance the line:

  window.document.menu5.visibility = 'hidden';

should be:

  window.document.getElementById("menu5").style.visibility = 'hidden';

when loaded in mozilla (that needs to be detected properly).

Since mozilla doesn't support the 4.x "layer" in any way I think this should
be marked WONTFIX, but I'll reassign to the parser people so that they can
decide what to do (if anything at all) about the data after the </HTML> tag not
showing up in the document, harishd?
Assignee: jst → harishd
Not a high priority. Moving to the FURTURE list.
Status: NEW → ASSIGNED
Target Milestone: M16 → Future
Keywords: nsbeta3
Removed nsbeta3 nomination from futured bugs.
Not JS Engine; updating component to Parser -
Component: Javascript Engine → Parser
Target Milestone: Future → mozilla0.9.1
Parser ignores /HTML, from the document, no matter where it appears. That is, 
markup after /HTML, in a document, will get parsed as though it appeared before 
/HTML. 
LAYERS == WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
->gerardok
QA Contact: ckritzer → gerardok
QA Contact: gerardok → bsharma
Marking verified as per above developer comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: