Bug 16781 – REGRESSION (r27271-r27279) inline visibility: hidden; ignored on submenus at wga.org

• Status: RESOLVED
• Resolution: FIXED
• Component: Evangelism

[Cameo Wood]

it looks to me like there are 4 menues all stacked on top of one another on the upper left. This page renders differently in IE/FF

ddkilzer> cameo: Happens with ToT WebKit on Leopard as well.

[Matt Lilek]

According to the web inspector, those menus have visibility: hidden; set via an inline stylesheet.  They do behave as expected after you hover over the tabs they belong to (the 8th menu belongs to the green, "online guild services").

Regression from Leopard Safari.

bisect-builds says:
Works: r27208  Fails: r27279

The most likely suspects in the above range are the CSS animated styles changes.

(In reply to comment #1)
> According to the web inspector, those menus have visibility: hidden; set via an
> inline stylesheet.  They do behave as expected after you hover over the tabs
> they belong to (the 8th menu belongs to the green, "online guild services").
> 

Inner children do have a computed style of visibility:visible, so they should be visible in WebKit. That is the case in both r27208 and TOT. Not sure what, if any, is the incorrect behavior in TOT.

Spoofing as Firefox fixes the bug. I think the menu library might be relying on Safari 2 behavior of not rendering visible descendants of invisible elements. However, I still cannot find the code change in the range given by bisect-builds where this should have changed for this particular case (it has already changed for most cases in Safari 3.0.4).

Narrowed down to r27271-r27279.

<http://trac.webkit.org/projects/webkit/changeset/27277#file56>

Antti and I think that the change was good and WebKit's current behavior is correct. Given that the site behaves correctly when spoofing as Firefox, this is really an evangelism bug.

[Antti Koivisto]

This change was fix to <rdar://problem/5521068>, reduction:

<div style="z-index:3;position:absolute;width:100%;height:100%;left:0;top:0;visibility:hidden"> 
    <div style="position:absolute;width:100%"> 
        <div style="visibility:visible;border:10px solid black"> 
            this should be visible
        </div> 
    </div> 
</div> 

(it was accidentally checked in as part of unrelated change)

Since this behavior matches Firefox and spoofing as Firefox fixes this bug it is highly likely that the website has a Safari specific code path that relies on the old behavior.

[Robert Blaut]

This code from menu.js is responsible for faulty rendering.:

var nua=navigator.userAgent,scriptNo=(nua.indexOf('Safari')>-1)?7:(nua.indexOf('Gecko')>-1)?2:((document.layers)?3:((nua.indexOf('Opera')>-1)?4:((nua.indexOf('Mac')>-1)?5:1)));
document.write("<SCRIPT SRC='"+awmMenuPath+awmLibraryPath+"/awmlib"+scriptNo+".js'><\/SCRIPT>")

If it detects Safari in UA it serves awmlib7.js which is currently broken. Firefox UA gets awmlib2.js which works fine.

[Robert Blaut]

Evangelism bug shouldn't have P1 priority.

[Robert Blaut]

The site renders correctly now in the latest WebKit. The bug is fixed :)