[10.5] Add roundness to context menus

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
P3
minor
VERIFIED FIXED
12 years ago
8 years ago

People

(Reporter: samuel.sidler+old, Assigned: mstange)

Tracking

({polish, verified1.9.1})

Trunk
mozilla1.9.2a1
PowerPC
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [radar:5430472][polish-hard][polish-visual][polish-p2])

Attachments

(3 attachments, 1 obsolete attachment)

In 10.5, context menus have rounded corners. We should have the same.
I believe bug 307204 is required for us to be able to do this. Not 100% sure.
Depends on: 307204

Comment 2

12 years ago
I don't want to "fake" that stuff with translucent windows. The rounded corners should be a window API option in 10.5, a switch we can flip. If that isn't the case we need to file an urgent bug with Apple to fix that.

Removing the dependency until we're sure these two are tied together.
No longer depends on: 307204
filed a request for rounded corners on NSWindow as rdar://problem/5430472
Whiteboard: [radar:5430472]
Got a response from Apple in the bug:

We need to set the window to transparent, and then use HITHemeDrawMenuBackround to draw the background, with kThemeMenuTypePopUp as the menuType param for the MenuDrawInfo.

Should be a piece of cake.
Adding CGContextClearRect() (which is what Apple suggested we use) in NS_THEME_MENUPOP and NS_THEME_MENUITEM seemed to do *something* on my 10.4 machine (added additional transparency). Tried it earlier today while sheriffing.
Duplicate of this bug: 391985
Assignee: joshmoz → cbarrett

Comment 7

12 years ago
Posted image screenshot 1
With the window set to .95 opacity following the steps in comments 4 and 5 leads to this (screenshot).
josh do you want to take back this bug, per our discussion a few days ago?
With all the work we've done to on controls it would be a shame if this bug got lost in the shuffle.

Nominating for blocking so we don't forget about it (p5 would be an appropriate priority, imo)
Flags: blocking1.9?

Updated

12 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
I assume this will also take care of the blurring that appears to go on behind menus on leopard? how about the fading out of menus as they close?
(In reply to comment #10)
> I assume this will also take care of the blurring that appears to go on behind
> menus on leopard? how about the fading out of menus as they close?

Probably to the first, no to the second.
Filed bug 406997 for the second.

Updated

12 years ago
Assignee: cbarrett → joshmoz

Comment 13

12 years ago
This is a purely aesthetic issue and not a regression. blocking1.9-
Flags: wanted1.9+
Flags: blocking1.9-
Flags: blocking1.9+
Priority: P5 → --
Duplicate of this bug: 414498

Comment 15

11 years ago
Any update on the status of the radar bug? I tried the steps in comment #4 and comment #5 on 10.5.2, but no rounded corners :-/
Flags: blocking1.9.1?

Comment 16

11 years ago
I can't imagine blocking on this but we want it for sure.
Flags: wanted1.9.1+
Flags: wanted1.9+
Flags: blocking1.9.1?
Flags: blocking1.9.1-

Updated

11 years ago
Priority: -- → P3
Depends on: 450091
Assignee: joshmoz → mstange
I'll work on this when bug 418454 lands (it changes some stuff about frame transparency).
Status: NEW → ASSIGNED
This patch is on top of those in bug 450939 and bug 450944.
I haven't tested in on 10.4 yet, it might mess things up.
The patch works on 10.4, too. Even there, HIThemeDrawMenuBackground draws outside the frame (i.e. the drawn rect extends 4px above and below the requested rect).

Comment 20

11 years ago
Do we really want it on 10.4?
The patch doesn't result in rounded corners on 10.4, HIThemeDrawMenuBackground does its job quite well. :-)

In comment 19 I meant to say that it doesn't break 10.4, i.e. it doesn't change the context menu's size there, although we make the drawRect smaller.
(In reply to comment #10)
> I assume this will also take care of the blurring that appears to go on behind
> menus on leopard?

It won't. And there's no way of doing that without using private, undocumented methods. :-(
Posted patch patch v1Splinter Review
Attachment #334362 - Attachment is obsolete: true
Attachment #343058 - Flags: superreview?(roc)
Attachment #343058 - Flags: review?(joshmoz)
Comment on attachment 343058 [details] [diff] [review]
patch v1

+    if (aTransparencyMode)
+      *aTransparencyMode = theme->GetWidgetTransparency(aDisp->mAppearance);

braces arond this non-control-flow statement
Attachment #343058 - Flags: superreview?(roc) → superreview+
Comment on attachment 343058 [details] [diff] [review]
patch v1

This patch isn't ready. :(
I just tested it again and noticed that it eats the shadow of XUL popup menus...
Attachment #343058 - Attachment is obsolete: true
Attachment #343058 - Flags: review?(joshmoz)

Comment 26

11 years ago
(In reply to comment #22)
> (In reply to comment #10)
> > I assume this will also take care of the blurring that appeas to go on behind
> > menus on leopard?
> 
> It won't. And there's no way of doing that without using private, undocumented
> methods. :-(
If aero glass was possible, maybe this is possible too ? As i look at latest iTerm.app code (with has abbility to set blur for transparent background) in cocoa you need only set prepared window filter with blur radious.
Attachment #343058 - Flags: review?(joshmoz)
Attachment #343058 - Attachment is obsolete: false
For some reason, mIsTransparent isn't set correctly on the view. I need to find out why that's the case, but for now this patch works.
Attachment #349939 - Flags: review?(roc)
(In reply to comment #26)
iTerm.app uses CGSAddWindowFilter; that's the private function I was referring to.

Updated

11 years ago
Attachment #343058 - Flags: review?(joshmoz) → review+
pushed: http://hg.mozilla.org/mozilla-central/rev/58f409bbc149
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Depends on: 469683
Depends on: 472734
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090129 Shiretoko/3.1b3pre Ubiquity/0.1.5
and 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre

10.4 builds still show square corners as expected.
Status: RESOLVED → VERIFIED

Comment 33

10 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090218 Minefield/3.2a1pre


My PPC machines have square corners under Leopard.
Whiteboard: [radar:5430472] → [radar:5430472][polish-hard][polish-visual]
This bug's priority relative to the set of other polish bugs is:
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable.

Context menus are a secondary interface, however this issue was widely reported on OS X as a polish problem.
Whiteboard: [radar:5430472][polish-hard][polish-visual] → [radar:5430472][polish-hard][polish-visual][polish-p2]
You need to log in before you can comment on or make changes to this bug.