|Summary:||REGRESSION (r27271-r27279) inline visibility: hidden; ignored on submenus at wga.org|
|Product:||WebKit||Reporter:||Cameo Wood <cameo.wood>|
|Severity:||Normal||CC:||dev+webkit, mitz, webkit|
|Version:||528+ (Nightly build)|
Description Cameo Wood 2008-01-07 21:19:15 PST
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.
Comment 1 Matt Lilek 2008-01-07 21:54:57 PST
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").
Comment 2 mitz 2008-01-07 21:57:59 PST
Regression from Leopard Safari.
Comment 4 mitz 2008-01-08 00:38:04 PST
The most likely suspects in the above range are the CSS animated styles changes.
Comment 5 mitz 2008-01-08 00:57:38 PST
(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.
Comment 6 mitz 2008-01-08 01:02:19 PST
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).
Comment 8 mitz 2008-01-08 11:39:23 PST
Comment 9 mitz 2008-01-08 11:45:14 PST
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.
Comment 10 Antti Koivisto 2008-01-08 11:52:39 PST
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.
Comment 11 Robert Blaut 2008-02-05 04:08:32 PST
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.
Comment 12 Robert Blaut 2008-02-11 04:06:58 PST
Evangelism bug shouldn't have P1 priority.
Comment 13 Robert Blaut 2008-12-26 11:38:09 PST
The site renders correctly now in the latest WebKit. The bug is fixed :)