Closed Bug 1159259 Opened 7 years ago Closed 6 years ago
[e10s] Link-related commands on context menu on sidebar links doesn't work
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
Actually, this doesn't work in single-process windows either, but I assume from the error message that this is a regression from 1133577.
It works correctly in release.
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.
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.
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.
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.
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.
Wontfix for 43. We could still take a fix here but I am dropping tracking since this was wontfixed 4 releases in a row.
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.
Neil, is this e10s specific?
Priority: -- → P1
I tried to reproduce this, but unfortunately setting a bookmark to open in a sidebar no longer works (filed bug 1258739)
Review commit: https://reviewboard.mozilla.org/r/55152/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55152/
Attachment #8756412 - Flags: review?(enndeakin)
Attachment #8756412 - Flags: review?(enndeakin) → review+
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
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=91fb2b109d9e Some oranges but all intermittents.
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.
(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.
Setting tracking-e10s=- based on Ian's comment 22 that this bug can affect non-e10s users, too.
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".
6 years ago
"Open in Sidebar"/the web-panel sidebar has been removed entirely in bug 1452645.
Hi, I think we can remove the QeVerify + flag since this option was removed entirely.I will mark this issue Accordingly.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.