With Nightly 47.0a1 (2016-02-26) on OS X El Capitan (10.11.3 (15D21)), when right clicking on the page to get the popup menu, and holding down the right mouse button, the entries for back, forward, reload, and star do not highlight correctly. When the cursor stops on an entry that should be enabled, it is not highlighted, and when the cursor moves, the entry gets a flickering highlight. Releasing the right mouse button on the entry does work as expected. A single-right click to access the page popup menu works fine. I noticed the problem on earlier Nightly builds as well. Firefox 44 doesn't have the problem for me.

Can you use mozregression to figure out when this broke? (moving to menus for now, but plausibly actually graphics or cocoa widget or layout... the regression window will help narrow down what's at issue here)

All testing done on OS X El Capitan (10.11.3 (15D21)), MacBook Pro (Retina, 15-inch, Mid 2015) with the exception that I also verified the problem occurs with the same OS X version on a Mac Pro (Early 2009) workstation running Nightly 47.0a1 (2016-02-26). I found that the problem only occurs in e10s mode. With much earlier revisions, the right-click-and-hold menu highlighting works correctly in both modes. And the behavior changed over time. It first regressed in this changeset window "hg log -r 372ce1f36116:5e9826980be5". More details below. With revision 372ce1f36116 (year-month-day 2014-09-02), the right-click-and-hold popup menu highlighting worked correctly in e10s and non-e10s modes. The next revision I could test with mozregression is 5e9826980be5 (2014-09-03) and with that rev, in an e10s window, the highlighting of the [back,forward,reload,star] icons does not work--there is no highlighting and no flicker. One of the changes in this set must have introduced that problem. i.e., before this changeset window it worked correctly in e10s and non-e10s mode. Afterwards, e10s mode had the no-highlighting problem. I used the following command to look at the changeset window. $ hg log -r 372ce1f36116:5e9826980be5 Later, a change in the set starting with 42afc7ef5ccb (2015-03-13) ending in 38154607d807 (2015-03-14) introduced the flicker first described in the bug report. To be clear, before this changeset window there was no highlighting at all (broken behavior), and after the window we get the flicker. This changeset window is probably less useful. Changeset window: $ hg log -r 42afc7ef5ccb:38154607d807 I attempted to drill down further, but ran into build failures of those older versions of the tree on El Capitan that I'm yet to debug.

Bug 1053716 - Mouse events over content-process area need to set capturing so that the entire mouse interaction is forwarded to the child.(In reply to Haik Aftandilian [:haik] from comment #2) > I found that the problem only occurs in e10s mode. With much earlier > revisions, the right-click-and-hold menu highlighting works correctly in > both modes. And the behavior changed over time. It first regressed in this > changeset window "hg log -r 372ce1f36116:5e9826980be5". More details below. Of the changes in "hg log -r 372ce1f36116:5e9826980be5", the one that sounds most related to this is. Bug 1053716 - Mouse events over content-process area need to set capturing so that the entire mouse interaction is forwarded to the child

reproduces on linux as well.

Felipe, can you investigate?

So what :gw280 suspected during the triage meeting is true. The problem is that, differently from Windows, on Mac/Linux the context menu is shown on mouse down (and not mouse up). But we still need to keep capturing the mouse to not regress bug 1053716. I don't know how to accomodate both requirements. We should probably look at what non-e10s does (I'm guessing onpopupshown calls release capture?). Let's see what Neil says. Odd that only the graphical items in the menu flicker, but not the traditional text ones.. Given that this is super polish-y and tracking+, I can't dig much further right now..

This still reproduces on the latest Aurora(46.0a2) and latest Nightly(47.0a1) builds, but only if e10s is enabled. I've tested this on a Mac Book Pro Retina, Mac OS X 10.11. User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160303004038 User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160303030253

One option is to clear the capture when a context menu is opened. This could also affect popups opened via left-click as well (<select> maybe?) and I don't want it to happen when a popup opens without clicking (password prompt), so I'm limiting this to context menus to avoid issues.

(In reply to Neil Deakin from comment #8) > Created attachment 8728569 [details] [diff] [review] > releasecapture-onpopupopen > > One option is to clear the capture when a context menu is opened. This could > also affect popups opened via left-click as well (<select> maybe?) and I > don't want it to happen when a popup opens without clicking (password > prompt), so I'm limiting this to context menus to avoid issues. I tested this on OS X with Nightly and it works well for me.

do we want to land this?

Comment on attachment 8748188 [details] [diff] [review] Release capture when a context menu is opened Seems reasonable.

https://hg.mozilla.org/integration/mozilla-inbound/rev/594736cae3ad287d2c145a1a5463f55a868246da Bug 1251634, release mouse capture when a context menu is opened, r=tn