https://bugzilla.mozilla.org/show_bug.cgi?id=34572

Bugzilla

Quick Search

[                    ]
  * Browse
  * Advanced Search

  * Reports
  * 
  * Documentation

  * New Account
  * Log In
    Sign in with GitHub or
    [                    ] [                    ]
    [password            ] [*] Remember [Log in]  
  * Forgot Password
    [                    ] [Reset Password]  

[moz]

  * Mozilla Home
  * 
  * Privacy
  * Cookies
  * Legal

Please enable JavaScript in your browser to use all the features on
this site.

Copy Summary
[                    ]
View V

  * Reset Sections
  * Expand All Sections
  * Collapse All Sections
  * 
  * History
  * 
  * JSON
  * XML

Closed Bug 34572 Opened 21 years ago Closed 28 days ago

Use native context menus on Mac OS

Summary:
Use native context menus on Mac OS

Categories

(Core :: Widget: Cocoa, enhancement, P1)

Product:
Core V
Core
Shared components used by Firefox and other Mozilla software,
including handling of Web content; Gecko, HTML, CSS, layout, DOM,
scripts, images, networking, etc. Issues with web page layout
probably go here, while Firefox user interface issues belong in the
Firefox product. (More info)
See Open Bugs in This Product
File New Bug in This Product
Watch This Product
Component:
Widget: Cocoa V
Core :: Widget: Cocoa
Mapping of cross platform widget interfaces to Mac Cocoa APIs.
See Open Bugs in This Component
Recently Fixed Bugs in This Component
File New Bug in This Component
Watch This Component
Version:
Trunk
Platform:
All
macOS
Type:
enhancement
Priority:
P1
Severity:
normal
Points:
---

Tracking

()

Status:
RESOLVED FIXED
Status:
RESOLVED
FIXED
Mark as Assigned
Milestone:
90 Branch
Iteration:
---
Project Flags:

Webcompat Priority [---]
Root Cause         [---]
a11y-review        [---]
user-doc-firefox   [---]
Fission Milestone  [---]

Tracking Flags:

                  Tracking Status
thunderbird_esr78 ---      wontfix
firefox-esr78     ---      wontfix
firefox88         ---      wontfix
firefox89         ---      fixed
firefox90         ---      fixed

                  Tracking   Status
relnote-firefox            [---]
thunderbird_esr78 [---]    [wontfix]
firefox-esr78     [---]    [wontfix]
firefox88         [---]    [wontfix]
firefox89         [---]    [fixed]
firefox90         [---]    [fixed]

People

(Reporter: mpt, Assigned: mstange)

Assignee:
# mstange
Assignee:
[ ] Reset Assignee to default
Mentors:
---
QA Contact:
[ ] Reset QA Contact to default
Reporter:
# mpt
Triage Owner:
# spohl
CC:
62 people

References

(Depends on 6 open bugs, Blocks 3 open bugs)

Depends on:
1703518, 1705157, 1706966, 1680177, 1700706, 1700710, 1700713,
1700715, 1701085, 1701243, 1702041, 1703272, 1703482, 1703927,
1703930, 1704127, 1704474, 1704883, 1704972, 1705120, 1706433,
1707204, 1707652, 1707869, 1710507
1700822, 1702129, 118025, 1692669, 1700732
1700727, 1691213, 1691861, 1694853, 1698662, 1698668, 1698997,
1699551, 1699582, 1699792, 1700679, 1700724, 1702387, 1702633,
1703617, 1704102
Blocks:
1687055, 7297, 13185, 39403, macmeta
1710459
proton-context-menus
Dependency tree / graph
Regressions:
---
Regressed by:
---
Duplicates:
37795, 196611, 239036, 240124, 1704306
URL:
 
See Also:
1656301, 1668119
jira.mozilla.com/browse/FFXP-108
jira.mozilla.com/browse/FIDEFE-1276

Details

(Keywords: helpwanted, platform-parity, Whiteboard:
[proton-context-menus][mac:mr1])

Alias:
---
Keywords:
helpwanted, platform-parity
Whiteboard:
[proton-context-menus][mac:mr1]
QA Whiteboard:
---
Has Regression Range:
---
Has STR:
---
Votes:
28
Bug Flags:

 behind-pref     [ ]
 firefox-backlog []
 sec-bounty      [ ]
 sec-bounty-hof  []
 in-qa-testsuite [ ]  [                    ]
 in-testsuite    [ ]
 qe-verify       []

Crash Data

Signature:

Security

(public)

This bug is publicly visible.

User Story

Bottom |
Tags V

  * Reset

Timeline V

  * Reset
  * 
  * Collapse All
  * Expand All
  * Comments Only

      Matthew T (active 1999-2002)
      Reporter
[628] Description                  

      *
      21 years ago

Mozilla on MacOS is using native main menus -- the XUL menu items are being
translated into native menu structures, allowing Mozilla to use the Mac's main
menu bar.

Why couldn't this be done with context menus as well? As far as I know, Web apps
don't have style access to (or even knowledge of) context menus, so the usual
skinnability arguments are not an issue. Using native menus would improve
internal consistency between Mozilla main menus and context menus (and between
Mozilla and other MacOS apps), as well as solving quite a few open bugs about
MacOS popup menus.

Implementing this could probably borrow heavily from the code already written for
making the main Mac menus.

      Mike Pinkerton (not reading bugmail)
      Comment 1
[b9e]                                      
      *
      21 years ago

i can't argue, but it's a time thing.

Status: NEW - ASSIGNED
Keywords: helpwanted
Target Milestone: --- - M20

      sairuh (rarely reading bugmail)
      Comment 2
[8df]                                 
      *
      21 years ago

*** Bug 37795 has been marked as a duplicate of this bug. ***

      sairuh (rarely reading bugmail)
      Updated
[8df]                                 
      *
      21 years ago

Keywords: pp

      Henri Sivonen (:hsivonen)
      Updated
[003]                           
      *
      21 years ago

Blocks: 39375

      Matthew T (active 1999-2002)
      Reporter
[628] Updated                      

      *
      21 years ago

Blocks: 39403

      Matthew T (active 1999-2002)
      Reporter
[628] Updated                      

      *
      21 years ago

No longer blocks: 39375

      Peter Trudelle
      Comment 3
[948]                 
      *
      21 years ago

Mass-moving all M20-M30 XPToolkit bugs to Future

Target Milestone: M20 - Future

      sairuh (rarely reading bugmail)
      Comment 4
[8df]                                 
      *
      21 years ago

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

QA Contact: sairuh - jrgm

      Matthew T (active 1999-2002)
      Reporter
[628] Updated                      

      *
      21 years ago

Blocks: 7297

      Blake Ross
      Comment 5
[9ca]               
      *
      21 years ago

How easy/hard would this be?

      akt
      Comment 6
[f12]               
      *
      21 years ago

I believe the following behavior is caused by this bug:

I have to "Turn off Contextual Menus in Mozilla 0.7" to see Mozilla's contextual
menus -- otherwise I get the "default" MacOS contextual menu (Help, Application
Menu, Refresh menus)

      Matthew T (active 1999-2002)
      Reporter
[628] Updated                      

      *
      21 years ago

Severity: normal - enhancement
OS: All - Mac System 8.5
Summary: Use native context menus on MacOS - Use native context menus
on Mac OS

      Matt Lee
      Comment 7
[318]               
      *
      21 years ago

The behavior being described by akt@yahoo.com above is caused actually by Apple
Data Detectors, an old software set that used AppleScript to open URLs embedded
in plain text. Its special contextual menus are available in all applications by
default, and you have to manually turn it off in apps that you don't want. It's
not relevant to this bug, as far as I can tell. (While I'm here, I'd like to
throw in my support for using the Mac's native menus.)

      Andrew Thompson
      Updated
[aff]                 
      *
      21 years ago

Blocks: 13185

      Andrew Thompson
      Updated
[aff]                 
      *
      21 years ago

No longer blocks: 13185

      nnooiissee
      Comment 8
[17d]               
      *
      20 years ago

just make sure the native menus still come up if the contextual menus extension
is not pressent. i for one loath that damnable thing--apple decided to wipe out
control key alias dragging, okay that was defacto, but not official, but
removing command-option dragging to copy and align? that dated back as far as i
have used mac os.

not that we needed contextual menus, mind you. oh well, maybe someday someone
will do something useful with them (rather than converting a working system,
xul, in a way that might break it (maybe this bug should at least depend on bug
51142).

      m_mozilla
      Comment 9
[f11]               
      *
      20 years ago

does this block bug 13185 ?

-matt

      Henri Sivonen (:hsivonen)
      Updated
[003]                           
      *
      20 years ago

Blocks: 13185

      Hixie (not reading bugmail)
      Updated
[839]                             
      *
      20 years ago

Depends on: 118025

      Hixie (not reading bugmail)
      Updated
[839]                             
      *
      20 years ago

Depends on: 118296

      Hixie (not reading bugmail)
      Updated
[839]                             
      *
      20 years ago

No longer depends on: 118296

      Frankie
      Comment 10
[96f]               
      *
      19 years ago

Does this bug affect OS X? If not, it should be WONTFIX.

      Chibi15
      Comment 11
[0e8]               
      *
      19 years ago

It does affect Mac OS X.

      Jo Hermans
      Comment 12
[dd4]               
      *
      19 years ago

*** Bug 196611 has been marked as a duplicate of this bug. ***

      Frankie
      Updated
[96f]               
      *
      19 years ago

OS: Mac System 8.5 - MacOS X

      David Douthitt
      Comment 13
[fed]                 
      *
      18 years ago

Not having standard MacOS contextual menus means that Chronos Software's
StickyBrain does not function with Mozilla at all, and thus significantly
affects the user's ability to use StickyBrain for its intended purpose.

Mozilla also needs to recognize AppleScript (I know Camino doesn't...)

      Simon Fraser [no longer active]
      Comment 14
[de8]                                 
      *
      18 years ago

> Mozilla also needs to recognize AppleScript (I know Camino doesn't...)

Sure they do. There isn't much support, but there's some. What do you need?

      Greg K.
      Comment 15
[530]               
      *
      17 years ago

*** Bug 240124 has been marked as a duplicate of this bug. ***

      Mano (::mano, needinfo? for any questions; not reading general
      bugmail)
[da1] Updated                                                        

      *
      17 years ago

Flags: blocking-aviary1.0mac?

      Kevin Gerich
      Comment 16
[50d]               
      *
      17 years ago

*** Bug 239036 has been marked as a duplicate of this bug. ***

      Mano (::mano, needinfo? for any questions; not reading general
      bugmail)
[da1] Updated                                                        

      *
      17 years ago

Flags: blocking-aviary1.0mac?

      louis bennett
      Updated
[ea4]                
      *
      17 years ago

Blocks: 262956

      louis bennett
      Updated
[ea4]                
      *
      17 years ago

Blocks: 101472
No longer blocks: 262956

      Mano (::mano, needinfo? for any questions; not reading general
      bugmail)
[da1] Updated                                                        

      *
      17 years ago

Blocks: macmeta

      Mano (::mano, needinfo? for any questions; not reading general
      bugmail)
[da1] Comment 17                                                     

      *
      17 years ago

I've started to work on this..

So far, i have an issue: DrawThemeMenuItem needs the menu rect (in addition to
the menuitem rect); how can i achieve it?

      David Catmull
      Comment 18
[6ae]                
      *
      17 years ago

I bet you can get away with using the same rect for both. I suspect OS 9's
beveled edges were mainly what made this important.

      Mano (::mano, needinfo? for any questions; not reading general
      bugmail)
[da1] Comment 19                                                     

      *
      17 years ago

(In reply to comment #18)
> I bet you can get away with using the same rect for both. I suspect OS 9's
> beveled edges were mainly what made this important.

Probably not, even HITheme api (10.3+) thinks it needs this information.

      Ben Fowler
      Comment 20
[722]               
      *
      17 years ago

(In reply to comment #17)
> I've started to work on this..

This report is marked as HELPWANTED . Do you have any design documentation?
Is there any way to speed your efforts on this 5 year old bug?

      Josh Aas
      Updated
[a8f]               
      *
      16 years ago

Assignee: mikepinkerton - joshmoz
Status: ASSIGNED - NEW

      Josh Aas
      Updated
[a8f]               
      *
      14 years ago

Assignee: joshmoz - nobody

      timeless
      Updated
[e4a]               
      *
      13 years ago

Component: XP Toolkit/Widgets: Menus - XUL
QA Contact: jrgmorrison - xptoolkit.widgets

      Florian Bender
      Comment 21
[89d]                 
      *
      8 years ago

Fixing this should fix quite a few other bugs, including future OS style changes, so yes please!

This bug should block Bug 565518.

      Jim Mathies [:jimm]
      Updated
[def]                     
      *
      5 years ago

No longer blocks: 101472

      Emilio Cobos Alvarez (:emilio)
      Updated
[1d9]                                
      *
      2 years ago

Component: XUL - Widget: Cocoa
Hardware: PowerPC - All

      Haik Aftandilian [:haik]
      Updated
[662]                          
      *
      8 months ago

See Also: - 1656301

      Haik Aftandilian [:haik]
      Updated
[662]                          
      *
      8 months ago

See Also: - 1668119

      Markus Stange [:mstange]
      Assignee
      Comment 22
[711]                          
      *
      6 months ago
      *
      Edited

I have started looking into this a bit.

I think the outline of the work would be roughly the following:

  * Decide which of our non-native menus we want to be native. I'm
    aware of the following categories:
      + Context menus
      + <select> popups
      + Bookmarks folders in the bookmarks toolbar
      + (Other types of panels / popups, such as arrow panels or
        tooltips, are out of scope for this bug.)
  * Decide what to do about various cases where our fake menus have
    "extra powers" compared to native menus. More on this below.
  * Create an API in widget/cocoa that allows opening a menu at a
    given coordinate for a given menupopup DOM node. We already have
    similar APIs for the main menu bar, for the application menu and
    Dock menu, and for menus for system status bar icons.
  * Hook into the various DOM APIs and nsXULPopupManager APIs that
    open menus, and call the new API on macOS instead of opening a
    fake menu.
  * Implement various custom menu item NSView subclasses for various
    special things (see below).
  * Make sure the various events that our front-end code expects are
    fired appropriately, e.g. popupshowing, popupshown, popuphiding,
    popuphidden.
  * Make sure DOM modifications are handled appropriately.
  * Make sure any custom menu items are accessible.
  * Check for performance problems. Maybe avoid layout work for
    native menus by making the "fake" menupopup display:none.
  * Deal with fallout in our automated tests. Any test that wants to
    interact with a context menu programmatically probably needs to
    disabled on macOS.

Notes on customizability

Native menus allow for a certain degree of customization by the app,
via custom NSViews that are shown instead of menu items. So that
means, for each horizontal row in a menu, we have the choice between
two options:

  * A native menu item, which can have a label, an icon, a checkmark,
    a submenu, and a shortcut key annotation. These menu items are
    displayed with the native style for the OS. Their styling cannot
    be customized, but we also do not need to maintain them because
    they automatically adopt the updated look of any new macOS
    versions. (Edit: As noted by Ken below, it is possible to set
    custom text styling by using an NSAttributedString as the label.)
  * Or a custom view. These views occupy the full width of the menu,
    and a custom height. They can have arbitrary content and user
    input handling. Any text styling, hover effects, click handling,
    flashing effects etc needs to be implemented manually. If there
    are visual elements in custom views that are intended to match
    the OS native look, then the code for these visual elements needs
    to be updated whenever a new macOS version with an updated look
    is released.

Notes on "extra powers"

I'm aware of three features our fake menus have, which I don't think
we can replicate in native menus:

  * [DEL:Handling of arbitrary modifier keys when clicking menu
    items: For example, if you click a bookmarks folder in the
    Bookmarks toolbar to display the folder contents in a menu, and
    then hold the Cmd key while clicking a bookmark item, the item
    will load in a new tab. If you try the same in a native menu, for
    example in the Bookmarks menu from the menubar, then the Cmd key
    is ignored and the clicked bookmark will open in the current tab.
    :DEL] Edit: This appears to be wrong, see the comments below. It
    looks like we can handle arbitrary modifier keys on native menu
    items.
  * "Menus on menus": For example, if you click a bookmarks folder in
    the Bookmarks toolbar, and then right-click a bookmark in the
    menu, you get a context menu that is displayed on top of the
    bookmarks folder popup. This is not possible with native menus -
    you cannot stack native menus, and you cannot right-click native
    menu items. (Or rather, right-clicking a native menu item will
    activate that item.)
  * Drag and drop of menu items: In bookmarks folder menus from the
    Bookmarks Toolbar, you can move and reorder bookmarks using drag
    and drop, even across different folders and submenus. This is not
    possible in native menus.

For these reasons, I think we should keep using custom menus for
bookmarks folders in the Bookmarks Toolbar. We may want to update
their styling to be explicitly different from native menus, so that
users can have the right expectations for what they can do with them.
Also, for right-click context menus inside the custom bookmark folder
menus, we can definitely use a native menu for the context menu.
As an alternative, we could decide to drop all this extra
functionality on macOS. For example, Safari doesn't let you do any of
the abovementioned things in their bookmarks toolbar.

Notes on "special things"

Most of our context menus only use basic menu elements and should
easily work as native menus. However, we would need custom NSView
implementations for the following:

  * For context menus:
      + The main content area context menu has a row at the top that
        shows four big icons: back, forward, refresh, bookmark. If we
        want to keep this custom icon row, we cannot use native menu
        items for these buttons, but we can implement the icon row
        with a custom view. This will require manually handling hover
        effects (including OS-specific visual styling of those hover
        effects) and click handling, including the flashing animation
        when an icon is clicked. The rest of the menu can be standard
        menu items.
  * For <select> popups:
      + If we decide to use native menus for <select> popups, we will
        probably need custom views for <optgroup> headers, and for
        items with custom styling (fonts, font styles, text color,
        background color). It's worth looking at Chrome's code for
        this (I haven't done that yet).
  * For bookmark folders from the bookmarks toolbar:
      + If we really want to use native menus for them, and keep
        their current feature set, then we'd need to do a ton of
        custom work here. I recommend against it. Let's keep using
        fake menus for them for now.

      Andrew Thompson
      Comment 23
[aff]                 
      *
      6 months ago

Excellent analysis. One comment:

" If you try the same in a native menu, for example in the Bookmarks
menu from the menubar, then the Cmd key is ignored and the clicked
bookmark will open in the current tab."

There is definitely some support for holding modifiers in native
menus in the main menu bar at least. E.g. go to the Finder and open
the File menu, then hold down Control, Option or Shift and observe
the menu items change.

Is it possible that the issue here is more specific? That you can't
hold down Cmd and get a different behavior?
Maybe the simpler fix there is to map the behavior to Opt rather than
Cmd (that's the key I would expect to use to modify behavior).

      Markus Stange [:mstange]
      Assignee
[711] Comment 24               

      *
      6 months ago

(In reply to Andrew Thompson from comment #23)

    Maybe the simpler fix there is to map the behavior to Opt rather
    than Cmd (that's the key I would expect to use to modify
    behavior).

That definitely sounds like a good option to consider!

      Ken Harris
      Comment 25
[063]               
      *
      6 months ago

Markus, that's a great start. A couple thoughts (as a Mac developer
who has fought with custom menus before):

  * You can handle modifier keys from stock menu items. I think
    Firefox should be improved to support cmd=newtab in the menu bar
    Bookmarks menu, as you suggest. Safari, in fact, supports exactly
    that feature! No need for custom menu items here, thankfully.

  * "Menus on menus" is such a strange interaction I wasn't aware
    Firefox did this. I tried it just now, and it's broken in several
    ways: the drawing is wrong, the mouse handling is wrong, and even
    keyboard shortcuts light up (but don't do anything) when it's
    open. It's downright hard to highlight or choose a menu item here
    just using the mouse normally. I've never seen any other Mac
    application have "menus on menus", and it breaks one of the most
    common standard menu operations (to be able to right-click on a
    menu item to choose it), so I would not be at all sad to see this
    removed.

Still, I do see value in being able to see a bookmark in a menu and
go directly to editing it, if a more Mac-like way could be found. A
common method I tend to see for "show me this in context" is holding
down command while choosing a menu item (e.g., holding command while
selecting an app from a folder's menu in the dock shows that app in
the Finder rather than launching it), but unfortunately "command" is
already used for "open in new tab". (Maybe "option"? In Safari,
option always means "download", but it seems to be unused in Firefox.
I don't know what the overall design for modifier keys in Firefox
is.)

  * It's true that if you use a custom NSView, you take on
    responsibility for all drawing and event handling, which is a
    pain. In my own application, I took a middle path: NSMenuItem has
    an "attributedTitle" property for using an NSAttributedString as
    its label. This makes it easy to make an ordinary menu item with
    a special font, or even insert images (with transparency) in the
    middle of the text. It's much easier than a custom NSView, as you
    don't have to re-implement all of the event handling by hand, or
    do extra work each year to support OS visual upgrades.

      Markus Stange [:mstange]
      Assignee
[711] Comment 26               

      *
      6 months ago

That's awesome feedback, thanks a lot!

      marczellm
      Comment 27
[97a]               
      *
      6 months ago

Let me provide an opposing perspective: as a heavily cross-platform
user across Mac, Windows and sometimes even Linux, I'd be annoyed if
the bookmarks toolbar supported different subsets of features on
different platforms. Right clicking on a bookmark anywhere and having
the same context menu actions on it is the most natural thing to me
and I wouldn't like it taken away.

      Michal Jakubowski
      Comment 28
[90d]                   
      *
      6 months ago

I'm a multiplatform guy (using Windows PC and MacBook Air with macOS
daily) and for me more annoying is having ugly context menu that does
not fit to the OS (and now even more annoying, one that does not
support dark mode).

      Cam
      Comment 29
[7df]               
      *
      6 months ago

If we get native context menus, I very much hope to be given the
option to deny extensions access to the context menu. As is I have to
use the following to be able to maintain a sane context menu.

#context-media-eme-learnmore + menuseparator,
#context-media-eme-learnmore + menuseparator ~ *,
 {
     display: none !important;
 }

      Markus Stange [:mstange]
      Assignee
[711] Comment 30               

      *
      6 months ago

All right folks, let's keep the rest of this bug focused on the
implementation. The first step will only be about context menus
anyway, and no loss of functionality is expected. If we do decide to
change anything about the bookmarks toolbar folder implementation, it
will happen later and in a different bug. I will link to that bug
here once we get to that stage. No more advocacy comments please.
As for the add-on entries in context menu issue, yes, the userChrome
CSS workaround from comment 29 will probably not work on native
context menus. We can file a new bug to determine whether that's
something we want to support.

      :Gijs (he/him)
      Updated
[664]                 
      *
      5 months ago

Blocks: proton-context-menus

      :Gijs (he/him)
      Updated
[664]                 
      *
      5 months ago

Whiteboard: [proton-contextmenu]

      Blake Winton (:bwinton) (:[?][?])
      Updated
[a4f]                               
      *
      5 months ago

Whiteboard: [proton-contextmenu] - [proton-context-menus]

      Mike Schreiber
      Comment 31
[836]                 
      *
      5 months ago

I'm pulling the Firefox source code now to look into this, but would
it make more sense for us to consider Photon-themed context menus
instead of going the native AppKit route? Greater UI consistency
within the app seems like an admirable goal, and it'd give us
flexibility to more easily incorporate nonstandard components like
the forward/back/bookmark controls, as well as the userChrome CSS
workaround from comment 29.

      Blake Winton (:bwinton) (:[?][?])
      Comment 32
[a4f]                               
      *
      4 months ago

Hi Mike! We have considered it, but decided to go with native context
menus on MacOS. (I don't have the full justification, but to me they
just feel more like a thing that should be native... :)

Thanks for the comment!

      Markus Stange [:mstange]
      Assignee
[711] Comment 33               

      *
      4 months ago

I'm starting to work on this now.

Quick status update:

  * For now, only context menus will become native.
  * Bookmark folder dropdowns will be styled in a Firefox-specific
    (non-native) way and retain their full functionality. This was
    decided with the involvement of the UX team.
  * <select> popups may become native at some point in the future but
    will stay non-native for now.

Assignee: nobody - mstange.moz
Status: NEW - ASSIGNED
Target Milestone: Future - ---

      Julien Chaupitre
      Updated
[9a3]                  
      *
      4 months ago

See Also: - http://jira.mozilla.com/browse/FIDEFE-57

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      4 months ago

Depends on: 1691213

      Julien Chaupitre
      Updated
[9a3]                  
      *
      4 months ago

See Also: http://jira.mozilla.com/browse/FIDEFE-57 - http://
jira.mozilla.com/browse/FFXP-108

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      4 months ago

Depends on: 1691861

      :Gijs (he/him)
      Updated
[664]                 
      *
      3 months ago

Depends on: 1692669

      Martin Balfanz [:mbalfanz]
      Updated
[5b6]                            
      *
      3 months ago

Whiteboard: [proton-context-menus] - [proton-context-menus][mac:mr1]

      Eiichi
      Comment 34
[0ab]               
      *
      3 months ago

Regarding <select>, please see also the bug 1571386.

      Blake Winton (:bwinton) (:[?][?])
      Comment 35
[a4f]                               
      *
      3 months ago

As per guidance from Vicky, for tracking, we're marking all the bugs
that people are working on as P1.

Priority: P3 - P1

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      3 months ago

Depends on: 1694853

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1698662

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1698668

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1698997

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1699551

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1699582

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1699792

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1680177

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700679

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700706

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700710

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700713

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700715

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700724

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700727

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700732

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1700822

      Soren Hentzschel
      Updated
[4f0]                  
      *
      2 months ago

Depends on: 1701085

      Soren Hentzschel
      Updated
[4f0]                  
      *
      2 months ago

Depends on: 1701243

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1702041

      Martin Balfanz [:mbalfanz]
      Updated
[5b6]                            
      *
      2 months ago

Depends on: 1702129

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      2 months ago

Depends on: 1702288

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

No longer depends on: 1702288

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1702387

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1702633

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1702664

      Markus Stange [:mstange]
      Assignee
[711] Comment 36               

      *
      2 months ago

Native context menus are now ready for testing on Nightly; all known
bugs are fixed. To enable native context menus on Nightly, set these
two prefs to true: widget.macos.native-context-menus and
browser.proton.enabled

Please file any bugs you find in the Widget:Cocoa component and make
them block this bug.

Thanks!

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      2 months ago

Depends on: 1703272

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      2 months ago

Depends on: 1703482

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1703617

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1703927

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1703930

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      2 months ago

Depends on: 1704127

      Stephen A Pohl [:spohl]
      Updated
[247]                         
      *
      2 months ago

Duplicate of this bug: 1704306

      Marco Bonardo [:mak]
      Updated
[0d6]                      
      *
      1 month ago

Depends on: 1704474

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

Depends on: 1703518

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

Depends on: 1704883

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

Depends on: 1704972

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      1 month ago

Depends on: 1705157

      Harry Twyford [:harry]
      Updated
[631]                        
      *
      1 month ago

Blocks: 1687055

      Julien Chaupitre
      Updated
[9a3]                  
      *
      1 month ago

See Also: - https://jira.mozilla.com/browse/FIDEFE-1276

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

Depends on: 1706433

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      1 month ago

Depends on: 1706966

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

No longer depends on: 1702664

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      1 month ago

Depends on: 1705120

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      29 days ago

Depends on: 1707204

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      29 days ago

Depends on: 1707652

      Emil Ghitta, QA [:emilghitta]
      Updated
[864]                               
      *
      28 days ago

Depends on: 1707869

      Markus Stange [:mstange]
      Assignee
[711] Comment 38               

      *
      28 days ago

Bug 1700679 enabled native context menus by default on Nightly
(Firefox 90), so this bug is now fixed!

Status: ASSIGNED - RESOLVED
Closed: 28 days ago
status-firefox88: --- - wontfix
status-firefox89: --- - affected
status-firefox90: --- - fixed
status-firefox-esr78: --- - wontfix
status-thunderbird_esr78: --- - wontfix
Resolution: --- - FIXED
Target Milestone: --- - 90 Branch

      Mehmet
      Comment 39
[121]              
      *
      28 days ago
obsolete

Comment hidden (obsolete) 

Can you please link Bug 1708017 to this one? Thanks :)

      Albert Scheiner [:alberts]
      Comment 40
[adb]                            
      *
      27 days ago



      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      26 days ago

Depends on: 1704102

      Pascal Chevrel:pascalc
      Comment 41
[529]                        
      *
      22 days ago

Fixed by uplift in 89 beta 8

status-firefox89: affected - fixed

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      15 days ago

Blocks: 1710459

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      15 days ago

Depends on: 1710507

      Mehmet
      Updated
[121]              
      *
      15 days ago

Depends on: 1710583

      Markus Stange [:mstange]
      Assignee
[711] Updated                  

      *
      13 days ago

No longer depends on: 1710583

      Morgan
      Comment 42
[3cf]               
      *
      13 hours ago

Greetings all! Firstly I just want to say I am very happy to see this
long standing bug fixed. Trying out Nightly all looks so much better
than the Firefox custom context menu so excellent job!

One thing I noticed was that the "Look Up" feature is not currently
supported/implemented in the context menu (at least as of 90.0a1
(2021-05-24)). Is this something that/will be added before release in
stable?

I am a huge user of the "Look Up" feature and I feel it is something
macOS users expect to see when right clicking a word in the browser.

      Albert Scheiner [:alberts]
      Comment 43
[adb]                            
      *
      12 hours ago

Hey Morgan, after a quick search I found this ticket bug 1116391. You
can follow it by hitting the "Follow" button at the top. You can also
add your vote. I saw that the last two comments were already marked
as "me-too", so adding another one of those won't do much good ;)
Hope that helps a bit.

You need to log in before you can comment on or make changes to this
bug.
Top |