1159259 - [e10s] Link-related commands on context menu on sidebar links doesn't work

Status: VERIFIED FIXED

(Firefox :: Menus, defect, P1)

Description

[Neil Deakin]

Steps:

1. Set a bookmark to open in the sidebar (Open properties for the bookmark and check the 'Load this bookmark in the sidebar' checkbox)
2. Open that bookmark. It will appear in the sidebar.
3. Open the context menu for a link on that newly opened sidebar.
4. Select 'Open in new tab'

Expected:
 Link opens in new tab

Actual:
 Nothing happens

Console error:
JavaScript error: chrome://browser/content/nsContextMenu.js, line 867: TypeError: gContextMenuContentData is null

Similar errors for other commands, open in new window, save link. Copy link works ok.

Comment 1

[Neil Deakin]

Bookmark link gives a different error:

Full message: ReferenceError: linkURI is not defined
Full stack: PlacesCommandHook.bookmarkLink<@chrome://browser/content/browser.js:5358:42
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
CM_bookmarkLink@chrome://browser/content/nsContextMenu.js:1559:1
oncommand@chrome://browser/content/web-panels.xul:1:1

Comment 2

[Neil Deakin]

Actually, this doesn't work in single-process windows either, but I assume from the error message that this is a regression from 1133577.

Comment 3

[Tracy Walker [:tracy]]

It works correctly in release.

Comment 4

[Jim Mathies [:jimm]]

Seems pretty corner case, not blocking.

Comment 5

[Ian Moody [:Kwan] (UTC+1)]

Attachment: sidebar-context.png

This is a regression from bug 1133577, but that is not the true cause.  It would appear the browser in the sidebar is not getting the content script browser/base/content.js loaded.  As such far more than just the link commands are busted, any content-menu command fixed to be free of unsafe CPOWs is now likely busted (many of the dependent bugs of bug 1109869).

Using the browser console to load the content.js script into the sidebar browser seems to be enough to fix this bug. 

However there seem to be other issues with the context menu in the sidebar. For instance it looks like the attachment to me.  The Navigation buttons all having right padding for some reason, and the stop button is never replaced with the reload one.  I wonder if some work similar to that in bug 782850 is needed to make the sidebar context menu more sane.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

From comment 5, sounds like this should also be related to bug 1109869.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Whether this is or isn't an e10s issue or should block, I think that it's a significant regression for context menu options to stop working.  My goal here is to find someone to work on this at some point. Maybe someone can take it on with 43 or 44 as their aim.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking as wontfix for 40-41. 

Javaun are these problems in the sidebar menus something you care about for 42 onwards? If so, can you suggest someone to have a look? And if not, I'll untrack this. I'll also try nominating this for firefox-backlog triage.

Comment 10

[Javaun Moradi [:javaun]]

Sorry Liz, I'm behind on NI's. I can't replicate, it seems to work as intended for me on OSX, I see the bookmark open in the sidebar.

I don't care about this one going forward. I'd be happy putting it into the normal backlog triage, it seems edge case.

Comment 11

[Vasilica Tamas, QA [:vtamas]]

I do not think this is an e10s issue because it is reproducible on Firefox 43 beta 7 (20151126120800) which is a non e10s build and also on Firefox 45.0a1 (2015-11-26) with e10s enabled/disabled and Firefox 44.0a2 (2015-11-27) with e10s enabled/disabled.

Tested on Ubuntu 14.04 64-bit, Mac OS X 10.11.1 and Windows 10 64-bit.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Wontfix for 43. We could still take a fix here but I am dropping tracking since this was wontfixed 4 releases in a row.

Comment 13

[Justin [:JW_SoftvisionQA]]

I can reproduce this issue on Beta 45.0b3 with e10s active and disabled. The links Open in new Tab, new Window, and new Private Window do not fire an action.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Neil, is this e10s specific?

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

I tried to reproduce this, but unfortunately setting a bookmark to open in a sidebar no longer works (filed bug 1258739)

Comment 16

[Ian Moody [:Kwan] (UTC+1)]

Attachment: MozReview Request: Bug 1159259 - Add content.js frameScript to the web-panel sidebar so link-related context commands will work

Review commit: https://reviewboard.mozilla.org/r/55152/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/55152/

Comment 17

[Neil Deakin]

Comment on attachment 8756412 [details]
MozReview Request: Bug 1159259 - Add content.js frameScript to the web-panel sidebar so link-related context commands will work

https://reviewboard.mozilla.org/r/55152/#review52450

Comment 18

[Ian Moody [:Kwan] (UTC+1)]

Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=91fb2b109d9e
Some oranges but all intermittents.

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ec1dd8da2504

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ec1dd8da2504

Comment 21

[Chris Peterson [:cpeterson]]

Ian, should we uplift this e10s bug fix from Aurora 49 to Beta 48? We plan to enable e10s by default for some release channel users with Firefox 48.

Comment 22

[Ian Moody [:Kwan] (UTC+1)]

(In reply to Chris Peterson [:cpeterson] from comment #21)
> Ian, should we uplift this e10s bug fix from Aurora 49 to Beta 48? We plan
> to enable e10s by default for some release channel users with Firefox 48.
Could do, it's a fairly straightforward fix, but it's not just broken in e10s, so the fact that that's being enabled shouldn't affect uplift considerations.

Comment 23

[Chris Peterson [:cpeterson]]

Setting tracking-e10s=- based on Ian's comment 22 that this bug can affect non-e10s users, too.

Comment 24

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I managed to investigate this bug on 49.0b8 build1 (20160829102229), using 
- Windows 10 x64
- Mac OS X 10.10.5
- Ubuntu 16.04 x64

These are the results: 
- With e10s on / off, "Save Link As...", "Save Link to Pocket" and "Inspect Element" context menu options are not working; the following errors are triggered in Browser Console, respectively: https://drive.google.com/file/d/0B0nYKG6PRiCcYVlNbDV3RGxxRDg/view?usp=sharing. This situation is also reproducible on Latest Nightly 51.0a1 (2016-08-31) and Latest Aurora 50.0a2 (2016-08-31);
- On 48.0.2 build1 (20160823121617), only "Bookmark This Link", "Copy Link Location" and "Search Google for..." context menu options are working, the rest of them throwing similar errors with the above mentioned ones;
- I also tried on latest Nightly the context menu options for other page elements, in the same situation (bookmark open in sidebar) and the following context menu options are not working, throwing similar errors with the above mentioned ones: "Save Page to Pocket", "Inspect Element" (for an empty place in the page, for an image, video element, audio element or for text),  "Save Audio As".

Comment 25

[Ian Moody [:Kwan] (UTC+1)]

"Open in Sidebar"/the web-panel sidebar has been removed entirely in bug 1452645.

Comment 26

[Rares Doghi, Desktop QA]

Hi, I think we can remove the QeVerify + flag since this option was removed entirely.I will mark this issue Accordingly.