Closed Bug 613905 Opened 14 years ago Closed 13 years ago

Superfish menu rendering with dark marks

Categories

(Core :: Layout: Block and Inline, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
mozilla2.0b10
Tracking Status
blocking2.0 --- final+

People

(Reporter: sunspikes, Assigned: MatsPalmgren_bugz)

References

(Blocks 1 open bug, )

Details

(Keywords: regression, Whiteboard: [softblocker])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

Go to the second menu from left (white one), try to access second level items from the menu 'Lorem ipsum', you can see the menu is rendering with some dark marks on the top right and bottom left sections.

This wont happen if you try this menu in any other browsers for example i have tried with FF 3.6, Chrome 7 and IE 8 on the same machine.

I have created another superfish menu in my local system which is also showing the same behavior.

Reproducible: Always

Steps to Reproduce:
1. Go to the we page: http://mehrpadin.net/demo/mpFREE/superfish
2. Access the dropdown menu from the second menu on the left side (white one)
Actual Results:  
You will see some dark marks while rendering the menu

Expected Results:  
Expected smooth rendering of the drop down menu as in the other browsers.
Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101121 Firefox/4.0b8pre ID:20101121044503

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94a0c347256d&tochange=8adb2f64c138
The following cset causes this.
082bd0be8bc0	L. David Baron — Clip contents of elements with overflow != visible to the border radius. (Bug 459144, patch 14) r=roc a2.0=blocking2.0:beta6

I am not sure this is regression or not.

WORKAROUND:
#menu-166-7 > UL
{
overflow:visible !important;
}
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Target Milestone: --- → mozilla2.0
Version: unspecified → Trunk
Alice0775's workaround seems to be working. But will this going be fixed in the core?
(In reply to comment #3)
> But will this going be fixed in the core?

Patience - this was barely filed 1 day ago. :)

The answer to your question, though, is "probably yes" -- the "blocking2.0: final+" flag on this bug (in the upper-right corner of this page) means that we're intending to fix this for the final release of Gecko 2.0 / Firefox 4.0.
Daniel Holbert, Thank you for your reply.
Mats, is this the same as bug 601512?
Assignee: nobody → matspal
At first glance - no.  Neither my "workaround" in bug 601512, nor updating
Cairo helps.  I do see my "FULLY CLIPPED" printf though, so it's probably
a related case.
Attached file Standalone testcase
There's no box-shadow involved, that was a red herring.

It appears to be caused by moving a positioned block that has border-radius.
This testcase could be reduced a lot more...
Fwiw, the animation is implemented using
jQuery.animate({opacity:'show',height:'show'}, ...)
Blocks: 459144
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Fwiw, I tried the patches in bug 602892 but it didn't help.
Worksforme with the latest nightlies on XP, Linux and Win7.
The problem disappears in this range for me:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a05e91710adb&tochange=c20f34eefa5d

Can anyone else still reproduce it with the latest nightly build?
Whiteboard: [softblocker] → [softblocker][worksforme?]
Still WFM in 2011-01-19 builds.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [softblocker][worksforme?] → [softblocker]
Target Milestone: mozilla2.0 → mozilla2.0b10
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: