548832 - vanguardschool.org - Z-Index Rendering Issue with Two Objects (DotNetNuke feeds IE-specific code to Firefox after document.readyState implementation)

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Shaun Lewis]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

There is an issue where the z-index of an element placed with javascript overlays over top of other elements on the page that have their z-index explicitly set higher. This is without regard to absolutely positioning or relative positioning.

On the example page, whenever a users mouses over a 1st-level menu item on the left hand side that has a submenu, the submenu is hidden behind the javascript-placed image. This is a guess at what is happening. This needs to be researched more. It could also be due to the face that the z-index is being set in the javascript as well. 

Reproducible: Always

Steps to Reproduce:
1. Place object (image only?) with javascript that's absolutely positioned and defines z-index
2. Place object on page that overlays the javascript-placed object and set its z-index
3. Non-javascript object will not displayed in the view hierarchy properly.
Actual Results:  
On the example web page, the views were rendered incorrectly. The submenu was hidden below the javascript-placed object.

Expected Results:  
The non-javscript object should have been overlaid above all the other objects.

Checked out in Webkit and Firefox 3.5. Issue does not exist there. It's specifically related to Firefox 3.6. Did not test on Windows, only on Mac OS.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note: the page has broken browser-sniffing, so you have to fake your UA to actually get the menus in builds other than official Firefox release builds....

Comment 2

[Boris Zbarsky [:bzbarsky]]

The behavior changed in this checkin range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9dbded90af2a&tochange=89811ac1b35a

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  So I'm still hunting down exactly why the behavior changed, but the code running on that site right now looks something like this:

  var iIndex = spm_getCurrentStyle(eMenu, 'zIndex');  //eMenu.style.zIndex;
  if (iIndex == null || iIndex == 0)
    eMenu.style.zIndex = 1;
  oIFR.style.zIndex=iIndex-1;

Now their spm_getCurrentStyle function is broken; what it does is:

  if (document.defaultView) 
  {
    // Get computed style information:
    if (el.nodeType != el.ELEMENT_NODE) return null;
    return document.defaultView.getComputedStyle(el,'')
                   .getPropertyValue(property.split('-').join(''));
  }

So in this case it does getPropertyValue("zIndex") instead of getPropertyValue("z-index").  The latter might return something.  The former always returns an empty string, since there is no "zIndex" CSS property. Then eMenu.style.zIndex is set to 1, while oIFR.style.zIndex is set to -1.

Of course the big question is what the heck eMenu and oIFR are. ;)  oIFR is an HTMLIFrameElement.  eMenu is an HTMLDivElement....

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  Now the images...  The images have their z-index set to auto.  Each one is in a <div class="slide"> that has z-index set to either 6 or 7.  These are all in a position:relative div with auto z-index.  So they end up at z-index 6 or 7 in the overall stacking order for the page.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  More investigation:

1)  The site runs totally different code in safari than it does in Mozilla.
    In particular spm_supportsIFrameTrick() returns false in safari, so the
    codepath described in comment 3 is never entered (because spm_iFrameIndex
    is never called).
2)  In Firefox 3.5, the codepath described in comment 3 is ALSO not entered,
    because of this check:

      if (document.readyState != 'complete')
        return;  //avoid operation aborted

    at the top of the spm_iFrameIndex() function.  Since Firefox 3.5 has no
    readyState support, that's comparing undefined to 'complete'.
3)  In Opera, the codepath described in comment 3 is ALSO not entered, because
    of this check:

      if (spm_browserType() == 'op')
        return;  //not needed

    at the top of the spm_iFrameIndex() function.

So this broke in 3.6 because we implemented readyState support.  The site explicitly does NOT run the broken code in Opera and Safari.  So that code only used to run in IE, and IE's handling of z-index for relatively positioned elements is broken: it treats z-index:auto the same way as z-index:0 for them, so the images end up at z-index 0, instead of z-index 6 or 7, in IE.  The broken code in spm_iFrameIndex() depends on this IE behavior, and used to only run in IE.  Now it runs in both IE and Firefox.... but that's not a Firefox bug.

Over to tech evangelism.  This site needs fixing.

Note: the relevant code is all in http://www.vanguardschool.org/controls/SolpartMenu/spmenu.js

Shaun, if you have contacts with the website's authors you may want to let them know about this problem.

Comment 6

[Shaun Lewis]

Wow. That was awesome. You are right. I incorrectly assumed it was Firefox just because it worked in all the other browsers except that one.

The author of the site is a company I work for (contract work sucks), however the SolpartMenu is a core component of DotNetNuke (which is terrible). Time to file a bug report with them, I suppose. In the mean time, I'm gonna try to patch the problem.

At any rate, I think this can safely be closed. Awesome detective work!

Comment 7

[Chris Lawson (gone)]

I'm gonna reopen this since it's a valid TE bug.

Shaun, please keep us posted on the status of the DotNetNuke bug. I assume this means it could potentially affect more than just the site mentioned here?

cl

Comment 8

[Boris Zbarsky [:bzbarsky]]

Shaun, the simplest way to patch locally is probably to bail out of spm_iFrameIndex early if spm_browserType() == 'mo'.

Comment 9

[Karl Dubost💡 :karlcow]

Since then the Web site has probably changed. 
http://www.vanguardschool.org/Default.aspx?tabid=113 is now 404.

Let's close it as INVALID.