144340 - DHTML broken in rv0.9.4 that worked rv0.9.2

Status: RESOLVED INVALID

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

Description

[shelby]

The drop down menus on our site work in rv0.9.2 (Netscape 6.1).  This has been 
reverified today.  The menus do not display (do not drop down) at all in 
rv0.9.4.

We had reported a bug, #98627:

http://bugzilla.mozilla.org/show_bug.cgi?id=98627

About the slowness of the page load due to these DHTML menus in rv0.9.2 (but 
this bug was later marked (not by us) as duplicate of general DHTML speed 
tracking bug, #21762).

Apparently in the process of trying to fix the speed of DHTML, Mozilla has 
managed to break what used to work.  These menus work in IE4+ and is now widely 
distributed for our 10000s of clients to drag+drop on their web pages.

What we will have to do is alter our menu code so that is degrades to inferior 
<SELECT> Netscape 4.7 functionality for 6.0 and 6.2+.  Yet it can do the nice 
DHTML menu for 6.1.  That is just wonderful progress guys!

I do hope you take this bug seriously (unlike every other report I've made), as 
my next action may be to start a campaign to convince the last Netscape 
diehards that the browser will forever be in beta.  We could do this simply by 
making the menu popup an alert in 6.x linking to these bug reports and stating 
that we've given up on Netscape/Mozilla, regardless of what AOL decides to do 
on distribution.

I don't start this way to introduce animosity.  Just to let you know that we 
have grown tired of tracking you guys.  It simply isn't productive any more.  
This is your last chance.

I used to be a big Netscape supported, even going to obvious great effort to 
make our products compatible with NN4.7 and 6.x, regardless of the miniscule 
marketshare.  The way our bugs have been handled has been a major turn off.

Please fix this bug.  And please don't close it, mark it as duplicate, or 
otherwise obfuscate it until it is fixed.

Thanks.

Comment 1

[Bob Clary [:bc] (inactive)]

not sure but this looks like a problem related to the change in the offset*
properties that occured in July 2001. The menu functions (in mozilla 1.0.0 from
5/12) but the popups are displayed offset from where they should be. 

http://www.downloadfast.com/dhtml_menu.js is obfuscated and contains:

// Copyright (c) 2001, Shelby H. Moore III
// All Rights Reserved
// Commercial use of this code, code derived from any portion or algorithms of
this code,
// without written permission, will be prosecuted and litigated to the full
extent of law.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Confirmed that this does not work in 0.9.4 and does work in a current trunk
build, as well as in 1.0rc2 (except the offset issue that Bob points out, in both).

Comment 3

[shelby]

Thanks guys!  You are making me a believer again :-)

If someone can point me to the details on changes to offset, I can probably 
figure out how to kludge the code to deal with such changes.  It was never 
quite clear to me which offsets to use for Mozilla.  I would have to look at 
the code again, but I thought I was using IE-specific offsets only for IE.  And 
I had to use some Netscape 4.7 offsets (innerWidth and innerHeight) because I 
was not aware of any W3C standards.  Please enlighten me.

I can provide the complete unobfuscated code but will not publicly.  Contact me 
via email if it is necessary.

I think the relevant code snippets are:


	// Position relative to parent?
	if( level > 1 )
	{
		var p = GetDocElementById( menus[/*extra space works around 
JMyth bug*/ level - 2] );
		if( o.style )
		{
			var top = y + (this.m_is_nav4 ? p.pageY : p.offsetTop);
			var left = (this.m_is_nav4 ? p.pageX + p.clip.width : 
p.offsetLeft + p.offsetWidth);

			// Reposition if menu would be clipped by window
			var t = (this.m_is_ie ? document.body.clientHeight : 
window.innerHeight) -
				(this.m_is_nav4 ? o.clip.height : 
o.offsetHeight);
			if( top > t )
			{
				top = t;
			}
			t = (this.m_is_ie ? document.body.clientWidth : 
window.innerWidth) -
				(this.m_is_nav4 ? o.clip.width : o.offsetWidth);
			if( left > t )
			{
				// put on other side of parent
				left = (this.m_is_nav4 ? p.pageX - 
o.clip.width: p.offsetLeft - o.offsetWidth);
			}

			o.style.top = top + "px";
			o.style.left = left + "px";
		}
		else
		{
			o.top = p.pageY;
			o.left = p.pageX + p.clip.width;
		}
	}

	if( o.style )
	{
		o.style.visibility = "visible";
	}
	else
	{
		o.visibility = "show";
	}


And:


// If input is < 0, then edge of viewport is used
function DHTMLMenu_PositionMenu( top, left )
{
	var o = GetDocElementById( this.m_menu_id );
	if( o.style )
	{
		o.style.top = ((top < 0 ? (this.m_is_ie ? 
document.body.scrollTop : window.pageYOffset) : top) + "px");
		o.style.left = ((left < 0 ? (this.m_is_ie ? 
document.body.scrollLeft : window.pageXOffset) : left) + "px");
	}
	else
	{
		o.top = (top < 0 ? window.pageYOffset : top);
		o.left = (left < 0 ? window.pageXOffset : left);
	}
}


And:


function DHTMLMenu_PositionMenuBelowTitle()
{
	// Netscape 4, IE3, or Netscape 6.0?
	if( this.m_is_nav4 || this.m_is_ie3 || this.m_is_moz091 )
	{
		// Must use WriteMenuTitle()
		return;
	}
	var id = this.m_menu_id + SafeHTMLIdString( "StartMenu" );
	var o = GetDocElementById( id );
	var x, y;
	if( this.m_is_nav4 )
	{
		x = o.pageX;
		y = o.pageY + o.clip.height;
	}
	else
	{
		for( x = o.offsetLeft, y = o.offsetTop + o.offsetHeight;
			(o = (this.m_is_ie ? o.offsetParent : o.parentNode)) 
			&& (this.m_is_ie || /*only element nodes*/o.nodeType == 
1)
			&& /*bugzilla#81290: before Netscape 6.1 does not get 
relative offset*/!this.m_is_moz092; )
		{
			x += o.offsetLeft;
			y += o.offsetTop;
		}
	}
	this.PositionMenu( y, x );
}

Comment 4

[Boris Zbarsky [:bzbarsky]]

I think Bob's referring to bug 116511 or bug 81290... I see your code is already
taking the latter into account.

I'm willing to take a stab at tracking down what the problem is.... Or do you
want to take this one, Bob?

Comment 5

[shelby]

Can you help me with more clues?

Could it be related to mozilla relative offset bug which we conditioned on 
v0.9.2?  You are saying the popup appears offset from hover point?  The 
following code snippet positions that.

See "bugzilla#81290" (bug #81290) in code snippet below:


		for( x = o.offsetLeft, y = o.offsetTop + o.offsetHeight;
			(o = (this.m_is_ie ? o.offsetParent : o.parentNode)) 
			&& (this.m_is_ie || /*only element nodes*/o.nodeType == 
1)
			&& /*bugzilla#81290: before Netscape 6.1 does not get 
relative offset*/!this.m_is_moz092; )
		{
			x += o.offsetLeft;
			y += o.offsetTop;
		}

Comment 6

[Boris Zbarsky [:bzbarsky]]

> You are saying the popup appears offset from hover point?

Yep.

I suspect that if you just make current Mozillas follow the IE branch in that
code (using offsetParent instead of parentNode) it will work as you want.

Comment 7

[shelby]

I will attempt your suggested changes in coming week or so.  Please do not 
close this bug until I have a chance to come back here and report my findings 
based on your suggestion.  I am too busy at the moment to do it immediately.

Thank you.

Comment 8

[Mathew McBride]

Should be *resolved* or *assigned* or something. Works in build: Mozilla/5.0
(Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608 (SeaMonkey Build) 

Comment 9

[Boris Zbarsky [:bzbarsky]]

No, this is not working in trunk build 2002-06-07-08 on Linux...

Comment 10

[shelby]

Have not YET had time to test this further or to look at possible solutions.

Are you saying that the menu works *AND* is not incorrectly offset in following 
version?

Mozilla/5.0
(Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608 (SeaMonkey Build) 

AFAIK, I do not currently have access to that version.  I do not have a test 
machine for installing and compiling experimental mozilla/gecko releases.  I 
wait for official Netscape releases.

If the menu works and is correctly offset in the latest version offset from 
(immediately adjacent and below) the hover point, then I would agree that it is 
resolved.

However, if there is still a problem with offset in the latest version, then I 
would ask for this to remain unconfirmed for a reasonable amount time until we 
can determine why the offset works in IE, worked in 0.9.2, but does not work in 
later versions.

Comment 11

[Markus Hübner]

is this evang?

Comment 12

[Markus Hübner]

think this has been fixed in the meantime - any objections?

Comment 13

[Frank Wein [:mcsmurf]]

Reporter: I think this had been fixed, does this problem still occour with a
newer build?

Comment 14

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK.  The menu comes up.  It's offset incorrectly because the code branch is
adjusting for bugs that NS 6.1 had in its emulation of some IE properties... but
we have since fixed those bugs.