Closed
Bug 548500
Opened 14 years ago
Closed 14 years ago
[Mac] Activate application when user selects dock menu item
Categories
(Firefox :: Shell Integration, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tom.dyas, Assigned: tom.dyas)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 3 obsolete files)
1.05 KB,
patch
|
asaf
:
review+
|
Details | Diff | Splinter Review |
1.72 KB,
patch
|
roc
:
superreview+
|
Details | Diff | Splinter Review |
I was testing the "New Window" item added by bug 415463 and noticed that Firefox did not come to the foreground when the menu item was selected while Firefox was not the active application. The attached patches fix this behavior. The application delegate in toolkit/xre/MacApplicationDelegate.mm already activates the application when the user was selected the dock menu item for a window. For custom items, however, we should allow the application to choose whether it should be activated. (For example, you can choose "Get New Mail" from the Mail.app dock menu without activating Mail.app.) I considered adding support to XUL for a custom attribute specifying whether to activate or not because rejected this idea as I'd rather not modify XUL for a Mac-only feature. The best place seems to be nsIMacDockSupport as this feature is in support of dock menu commands.
Attachment #428874 -
Flags: review?(joshmoz)
Attachment #428876 -
Flags: review?(mano)
Forgot to bump the IID on nsIMacDockSupport.
Attachment #428874 -
Attachment is obsolete: true
Attachment #428879 -
Flags: review?(joshmoz)
Attachment #428874 -
Flags: review?(joshmoz)
Comment 4•14 years ago
|
||
Comment on attachment 428876 [details] [diff] [review] firefox v1 r=mano
Attachment #428876 -
Flags: review?(mano) → review+
Attachment #428879 -
Flags: review?(joshmoz) → review+
Comment on attachment 428879 [details] [diff] [review] widget v2 This needs obj-c exception guards, you can fix that on checkin. NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT NS_OBJC_END_TRY_ABORT_BLOCK_NSRESULT
Add Obj-C exception guards. Does the interface change needs superreview? Josh: I don't have committer access so I'll just flag it for check-in unless you can get to it (assuming it doesn't need superreview).
Attachment #428879 -
Attachment is obsolete: true
#include file was in second patch not first ... fixed now
Attachment #429536 -
Attachment is obsolete: true
Attachment #429537 -
Attachment is patch: true
Attachment #429537 -
Attachment mime type: application/octet-stream → text/plain
Attachment #429537 -
Flags: superreview?(roc)
Comment on attachment 429537 [details] [diff] [review] widget v3.1 Technically this does need sr.
Attachment #429537 -
Flags: superreview?(roc) → superreview+
Keywords: checkin-needed
Whiteboard: Check in both patches to trunk.
Assignee | ||
Comment 10•14 years ago
|
||
Saw that roc landed both patches on trunk: http://hg.mozilla.org/mozilla-central/rev/290ebc6801ad http://hg.mozilla.org/mozilla-central/rev/f07ed8839916
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: Check in both patches to trunk.
Thanks!
You need to log in
before you can comment on or make changes to this bug.
Description
•