What steps will reproduce the problem? 1. Go to http://db.mmo-champion.com/ 2. Open the Web Inspector 3. Hover the links under the search box What is the expected result? Dropdown menus should be shown What happens instead? The menus stack all together (upstreamed from Chromium http://code.google.com/p/chromium/issues/detail?id=16949)
I'm going to go with my instinct: The hover creates a menu. This menu is an <ul>; the ul is a child of an <a> tag. This is very broken html. I'm going to try make a reduced testcase this afternoon.
Okay, two notes: - The behaviour on the linked page happens *all the time* with the web inspector open, and *rarely* with the web inspector closed. - While reducing, I was able to come up with a test case that would *always* reproduce the problem even with the web inspector closed. It might be safe to change the bug's component. Cleaning up and attaching the testcase.
Created attachment 33952 [details] Reduced testcase There's the "cleaned up" reduced testcase. The web inspector no longer needs to be opened to reproduce. Tested against firefox 3.0 and 3.5.
To clarify the issue... The <ul> is removed and added by javascript as a child of a <span> element (not <a>). This is of course "bad html" as it's a block element inside an inline element. The bug is that the line breaks created by the <ul> being display: block aren't removed when the <ul> is. Changing to the <ul> to display: inline before removing the <ul> removes the line breaks first, preventing the bug from appearing. I don't know if this effects other block elements used within inline elements.
Created attachment 33953 [details] Further reduced test case Reduced javascript, number of elements and type of elements.
Created attachment 33954 [details] Further reduced test case file Reduced javascript, number of elements and type of elements. Uploaded test case file.
+HasReduction please.
Still in 535.18.
The behavior in WebKit r131018 matches that in FireFox 15.0.1 - please double-check and close the bug if appropriate.
(In reply to comment #9) > The behavior in WebKit r131018 matches that in FireFox 15.0.1 - please double-check and close the bug if appropriate. Looks fixed.