Closed Bug 595842 Opened 12 years ago Closed 12 years ago

Windows native theme drawing draws nothing when inside a rounded rectangle clip region (i.e., form controls blank when they or an overflow:hidden ancestor have 'border-radius')


(Core :: Widget: Win32, defect)

Not set



Tracking Status
blocking2.0 --- beta7+


(Reporter: stanley.appel, Assigned: roc)




(Keywords: regression)


(2 files, 1 obsolete file)

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

When visiting there are no checkboxes and radiobuttons shown.


Good: 20100909041137

Bad: 20100910041829

Reproducible: Always

Steps to Reproduce:
1. visit url
Actual Results:  
no checkboxes

Expected Results:  

Mind that build 2010-09-12 en higher show a script busy error which might be from the JM+TM merge. 

but the problem is from BEFORE this merge.
Keywords: regression
Version: unspecified → Trunk
>Mind that build 2010-09-12 en higher show a script busy error which might be
>from the JM+TM merge. 
>but the problem is from BEFORE this merge.

Filed Bug 595846
Using Firebug i get Checkboxes if i disable
"border-radius" Style in
#content .columns li .content {
    border-radius: 0 6px 6px 6px;

or the "overflow" Style in
#content .columns li .content {
    background: none repeat scroll 0 0 #FFFFFF;
    border: 1px solid #999999;
    line-height: 18px;
    margin-top: -1px;
    overflow: hidden;

Looking at the given Regrange this seems to be caused by Bug 451134. No Idea if this is a valid Bug or invalid/TE Bug ....
Severity: major → normal
Component: General → Style System (CSS)
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → style-system
Hardware: x86 → All
This is WFM now using Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100918 Firefox/4.0b7pre ID:20100918130228.
Since it is also working with a Build this was filed against, i guess the Site changed.
Probably bug 595842 (this bug), bug 596205, and bug 596271 are related.
I played around with a testcase a bit in a Windows build today, and it's reasonably clear that the problem is that native theme drawing simply stops drawing anything when it happens inside a rounded-rect clip region.!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Adiv%20%3E%20*%20%7B%20-moz-appearance%3A%20xnone%20%7D%0Adiv%20%7B%20overflow%3Ahidden%3B%20border-radius%3A%201px%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%0A%20%20%3Cinput%20type%3Dradio%3E%0A%20%20%3Cinput%20type%3Dcheckbox%3E%0A%20%20%3Cselect%20size%3D%221%22%3E%3C%2Fselect%3E%0A%20%20%3Cselect%20size%3D%223%22%3E%3C%2Fselect%3E%0A%3C%2Fdiv%3E

was what I was playing with:  if you change 1px to 0px, you see controls.  If you change 'xnone' to 'none', you see controls, except for the native scrollbars inside them.
blocking2.0: --- → betaN+
Component: Style System (CSS) → Widget: Win32
Ever confirmed: true
QA Contact: style-system → win32
Summary: No checkboxes/radiobuttons on page → Windows native theme drawing draws nothing when inside a rounded rectangle clip region (i.e., form controls blank when they or an overflow:hidden ancestor have 'border-radius')
Duplicate of this bug: 596205
Duplicate of this bug: 596271
The reason this is suddenly a problem now is that bug 459144 was fixed.
Blocks: 459144
[2010-09-20 13:43:05] <robarnold> dbaron: pretty sure I've run into this bug. The underlying cause is a clip with non-integral coordinates causes us to fail to get an HDC for drawing. This happens in gfxNativeWindowsDrawing I think
Assigning to cpearce just for fun!
Assignee: nobody → chris
FWIW, I debugged this to the point of finding (if I've put the implications of my printfs together correctly) that in gfxWindowsNativeDrawing::BeginNativeDrawing, we return a null dc because mWinSurface->GetDCWithClip(mContext) returned null.
Oh, one other thought:  Either (a) there's an easy way to make it not return null and have the right clip set, in which case we want to use that or (b) we may want to take the fallback path.  But if we take the fallback path, we probably want to intersect the clip region with the maximal area that the control can cover, since that might get us a simpler clip region and avoid the fallback path in most cases.

Then again, this is well into the area where I don't particularly know what I'm talking about.
Duplicate of this bug: 600276
just ran into this recently as well (i think) with overflow:auto. gonna vote it. attaching reduced testcase.
WRT comment #14 that's basically same as:

from bug #596271  :)

just using overflow instead of overflow-x - but that's basically the same.
Duplicate of this bug: 601911
Duplicate of this bug: 603164
Blocks: 603120
Blocks: 603049
Duplicate of this bug: 603415
I think this is high-profile enough that we need to fix it sooner rather than later, so pulling in to beta8.  It's already accumulated 6 duplicates without being shipped in a beta (though it has been on mozilla-central for 5 weeks).
blocking2.0: betaN+ → beta8+
Attached patch Patch v1 (obsolete) — Splinter Review
Just taking the fallback doesn't work here, because when we take the fallback path when a theme claims it supports a widget but actually fails to draw in the theme, in nsCSSRendering::PaintBorderWithStyleBorder() we'll assume the theme drew the widget's border when we called nsITheme::DrawWidgetBackground, and so we'll not draw the border on the fallback path. But if the theme failed to draw, the assumption that the theme drew the border is incorrect, so we won't end up with a border at all.

So this patch fixes this another way... We simply takes a non-clipped HDC when GetDCWithClip() fails in gfxWindowsNativeDrawing::BeginNativeDrawing(). I know very little about any of this code, so I dunno if this is unsafe, but it at least works with all the test cases in all the bugs which are dupes of this one. Plus it actually draws the widgets with the theme, so they look pretty.

What tests should I run to test this?
Attachment #484594 - Flags: review?(roc)
With this patch, do the form widgets get clipped appropriately if they're actually near the edge?
(In reply to comment #21)
> With this patch, do the form widgets get clipped appropriately if they're
> actually near the edge?

Hmm, it looks like we're drawing extra dot-borders around focused check boxes, which is not ideal. Looking back at the nightly from 1 Sep, we didn't do this, so it's guessing it's a problem with this patch. Better investigate...
Assignee: chris → roc
Attached patch fixSplinter Review
Just taking the fallback path if mDC is null seems to work fine for me.
Attachment #484594 - Attachment is obsolete: true
Attachment #486251 - Flags: review?(vladimir)
Whiteboard: [needs landing]
Now that we ship beta7 from mozilla-central, shouldn't this block beta 7? It's a highly visible malfunction of the UI, especially for the new add-ons manager.
blocking2.0: beta8+ → beta7+
Closed: 12 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Depends on: 608199
The test is failing on Win7 opt:

It looks like the clipping to the border-radius is causing the border to be antialiased differently.

Checked in a fix to remove black border, as it's not really necessary for the test:
Duplicate of this bug: 603049
Duplicate of this bug: 603120
No longer blocks: 603049
No longer blocks: 603120
Verified fixed with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101029 Firefox/4.0b8pre given the testcase in comment 0 and the new Add-ons Manager.

Setting the TM to b8 because I think we will mass-update the TM at some point for all fixed bugs.
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.