Closed Bug 950511 Opened 8 years ago Closed 7 years ago

OS X Context Menu uses incorrect Antialiasing Settings even on non-HiDPI screens


(Core :: Widget: Cocoa, defect)

29 Branch
Not set



Tracking Status
firefox27 --- unaffected
firefox28 --- unaffected
firefox29 --- fixed
firefox30 --- fixed


(Reporter: armin.ronacher, Assigned: mstange)



(Keywords: regression)


(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20131215030202

Steps to reproduce:

Clicked right to open a context menu in the browser.

Actual results:

The dialog did not use the correct antialiasing settings.  The font rendering uses grayscale antialiasing.

Expected results:

I expected subpixel rendering for this menu like any other OS X dropdown.
This occurred first in today's nightly and it did not happen before.  It can easily be checked by making a screenshot and zooming in on it.  In Nightly the pixels will be gray whereas a screenshot of a Cocoa context menu will show colored pixels upon zooming in from the subpixel rendering algorithm.
Component: Untriaged → Widget: Cocoa
Keywords: regression
Product: Firefox → Core
(In reply to :Gijs Kruitbosch (Extremely limited availability until Dec. 18, then PTO until January 2) from comment #4)
> Markus/Steven

Egh, bugzilla fail. Markus, Steven, any idea what's going on here?
Flags: needinfo?(smichaud)
Flags: needinfo?(mstange)
(In reply to Armin Ronacher from comment #1)
> This occurred first in today's nightly and it did not happen before.

Can you doublecheck it did not occur in the Nightly from the 14th? It's generally very helpful if we have as narrow a regression range as possible. :-)
I can confirm it works with the "2013-12-14-03-02-04-mozilla-central" nightly.
(In reply to Armin Ronacher from comment #9)
> I believe that would be any of those changes:
> pushloghtml?fromchange=9d593727eb94&tochange=c049cb230d77

Thanks! Close, but it should be:

(that's mozilla-central vs. mozilla-inbound)

That shows:

47aac229cc2d	Benoit Girard — Bug 941095 - Part 2: Disable subpixelaa + component alpha. r=mattwoodrow
7b9ff0798201	Benoit Girard — Bug 941095 - Part 1: Support SetPermitSubpixelAA with Quartz. r=bas

Which sounds highly relevant. There are comments on that bug also lamenting this change. Marking this blocking the other bug. :-)
Blocks: 941095
Ever confirmed: true
Flags: needinfo?(smichaud)
Flags: needinfo?(mstange)
I should point out that this is on a non retina screen notebook obviously but it is a higher than normal DPI screen (1680 x 1050 resolution).
Context menus have text on transparent background and no opaque backdrop to blend with, that's probably why they get subpixelAA disabled even on non-HiDPI displays.
The context menu background is roughly rgba(255, 255, 255, 0.95), so there's still enough of a background to do meaningful subpixelAA blending with, even if it's not completely opaque.

Why do we turn off subpixelAA when drawing into transparent surfaces? Is it because Windows subpixelAA text rendering is buggy when we do that? Should we special-case Mac here?
Summary: OS X Context Menu uses incorrect Antialiasing Settings → OS X Context Menu uses incorrect Antialiasing Settings even on non-HiDPI screens
I know it looks like a really insignificant issue but font rendering being wrong makes an application immediately feel non-native.  I would really appreciate if this was fixed :)
I don't think this is cased by 941095. I have the changes backed out locally and I still see this.
Do you have both patches backed out locally or just part 2?

This is almost certainly caused by part 1's patch.
I'm going to back out part 1, on both mozilla-central and aurora.
Assignee: nobody → mstange
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.