In nsDeviceContextMac :: GetSystemFont we have the following code: 282 if (aID == eSystemFont_Window || 283 aID == eSystemFont_Document || 284 aID == eSystemFont_Button || 285 aID == eSystemFont_PullDownMenu || 286 aID == eSystemFont_List || 287 aID == eSystemFont_Field) { 288 aFont->name.Assign(NS_LITERAL_STRING("sans-serif")); 289 aFont->size = NSToCoordRound(aFont->size * 0.875f); // quick hack 290 } At least for eSystemFont_List this is utterly wrong -- see bug 53617

From the "parent" bug 25657: James Lariviere wrote: > mozilla uses a fixed font for > textareas while everything else is proportional. Seems reasonable that > textareas should use the same font as the other controls. And, just to be clear, this should surely default to monospaced (so that the WIDTH attribute of TEXT TYPE="INPUT" actually has any useful function in HTML at all), and only become proportional/variable width IF the page author manually codes it that way. Right?

No, it should be monospace for input text, we are now using sans-serif, which is what IE uses which is what most people now expect.

cc'ing myself

This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".

Simon, does OSX share this code?

Yes

This bug hasen't been touched for years and is clearly unowned. Moving back to default assignee/QA so that people, who are watching those can accurately triage this bug. Also resetting Priority, Target Milestone, Status Whiteboard and Status.

Not sure whether this is still an issue with thebes, but over to the right component for now. It does look like nsSystemFontsMac::GetSystemFont no longer has this bug.

Yeah, it only does it for font: -moz-window and -moz-document now, and I don't see those being used anywhere.