[Mac] Disabled, checked checkbox does not appear checked



14 years ago
10 years ago


(Reporter: jruderman, Assigned: jaas)


({regression, testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



Steps to reproduce:
1. Load data:text/html,Foopy: <input type=checkbox checked disabled>

Result: The checkbox doesn't appear checked.  If you're very perceptive, you might notice that the check does appear, but in the wrong place: at the top left of the content area.

Regression window:

2006 Jan 25 evening: fine
2006 Jan 26 evening: has the bug
2006 Feb  2 evening: has the bug

Based on the regression date, guessing that this regressed due to frame display lists.
I noticed this because Bugzilla shows a disabled, checked checkbox if you view a bug that is restricted to a group, but you're not part of the group (e.g. you're the reporter).
Keywords: testcase
So this seems to not be a problem on Linux, which suggests native theme issues to me.  In particular, the coordinate system for painting changed; was native theme code not fixed to deal?

Is this a problem on WinXP too?
Not a problem on Windows XP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060131 Firefox/1.6a1
Summary: Disabled, checked checkbox does not appear checked → [Mac] Disabled, checked checkbox does not appear checked
Probably an nsNativeTheme thing.
Assignee: nobody → bugs.mano
Component: Layout: Form Controls → Widget: Mac
QA Contact: layout.form-controls → mac
Target Milestone: --- → mozilla1.8.1
Assignee: bugs.mano → joshmoz
Target Milestone: mozilla1.8.1 → ---
(In reply to comment #4)
> Probably an nsNativeTheme thing.

Jesse says this is a regression for html content, which isn't drawn by nsNativeThemeMac at all (in anything but Camino).
Flags: blocking1.9a1?
Is this bug 325296, too (or the issue that bug 325296 is left open to track)?
Flags: blocking1.9a1? → blocking1.9+
Could it be a bug in the non-native-theme codepath that's covered up whenever native theme is used?
This WFM in GPA3 and my latest Camino trunk build.
Target Milestone: --- → mozilla1.9alpha6
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
WFM on 2007081600 OS X 10.4.10.  

Does it really make sense to keep it blocking1.9+ even if it's carbon-only (AFAICS)?
WFM on trunk.
Closed: 12 years ago
Flags: blocking1.9+
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.