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 https://mijndvn.nl/profile/registration/index/ailment/diabetes there are no checkboxes and radiobuttons shown. regression: Good: 20100909041137 http://hg.mozilla.org/mozilla-central/rev/8e0fce7d5b49 Bad: 20100910041829 http://hg.mozilla.org/mozilla-central/rev/79d0beec27b5 Reproducible: Always Steps to Reproduce: 1. visit url 2. 3. Actual Results: no checkboxes Expected Results: checkboxes 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.

>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 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e0fce7d5b49&tochange=79d0beec27b5 this seems to be caused by Bug 451134. No Idea if this is a valid Bug or invalid/TE Bug ....

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. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!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.

The reason this is suddenly a problem now is that bug 459144 was fixed.

[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!

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.

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: https://bugzilla.mozilla.org/attachment.cgi?id=475576 from bug #596271 :) just using overflow instead of overflow-x - but that's basically the same.

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).

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?

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...

Just taking the fallback path if mDC is null seems to work fine for me.

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.

I agree.

The test is failing on Win7 opt: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288335147.1288336873.7236.gz 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: http://hg.mozilla.org/mozilla-central/rev/799a83ba5f86

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.