Affected versions

• Firefox 88.0b3
• Firefox 89.0a1

Affected platforms

• Windows 10
• macOS 10.15.7

Steps to reproduce

1. Launch Firefox
2. Open Pocket menu from the toolbar
3. Right click on the Pocket panel

Expected result

• Specific context menus for the panel are shown

Actual result

• All the context menus are shown

Regression range

• Will see for a regression

Additional notes

• The issue can be seen in the following attachment
• Ubuntu doesn't seem to be affected

This seems to be an old regression (2019):

• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=522a2bc06f9e5d0767bb3f2e127cc21eeaeb8a78&tochange=b5355bd2162ba5740469820ee518649e7fc0b953

• Potential regressor: From the generated pushlog, Bug 1505909 seems to have touched the context menu area.

Mike, can you please take a look? (Sorry if it turns out that I've pinged the wrong potential regressor).

Dropping this from Proton tracking given the issue predates proton.

Clearing the priority set in comment 1, since this predates Proton.

I'm hoping the Pocket folks have cycles to look at this more.

Push to try (the other test did all pass for me locally, but I also added couple more tests in a test to cover this issue with some more explicit test coverage even if minimal, I pushed it including --verify to double-check if that part may become a source of intermittency):

• https://treeherder.mozilla.org/#/jobs?repo=try&revision=0e904e1948f0b62ae3f3f29dea01593bc1494f50

Backed out changeset d0e9b3b951f8 (Bug 1701152) for causing failures in browser_toolbarButtonKeyPress.js CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=d0e9b3b951f8873c5c0c98dc701a76c5f7762160&selectedTaskRun=U1VXYUfgRQGs7GG1I8qy-Q.0

Log: https://treeherder.mozilla.org/logviewer?job_id=338343468&repo=autoland&lineNumber=2300

Backout: https://hg.mozilla.org/integration/autoland/rev/e276f601e5ee51d936173674ccb589718c6a26be

eh, well I wasn't really expecting a test from browser/base/content/test/keyboard/browser_toolbarButtonKeyPress.js to be expliclitly checking if the pocket button do use an iframe for the panel, and I did not notice it in my first push to try.

I'll update the patch accordingly (also look if there was some other one like this around the mozilla-central tree).

https://hg.mozilla.org/mozilla-central/rev/1771d37af4a7

The patch landed in nightly and beta is affected.
:rpl, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

The bug itself doesn't seem too critical, it just looks bad if the user happen to right click in the pocket panel but it shouldn't be breaking anything for the pocket toolbar button panel on its own.

The fix should be low risky (in the end it is "a couple of lines" fix + 99% tests), but I would leave the final choice to the Pocket engineers.

This is a P5/S3, we have had this bug for 2 years and we are preparing beta 12, I think this fix can ride the 90 train, thanks.