Closed Bug 1047751 Opened 10 years ago Closed 10 years ago

[e10s] context menu is completely broken on https://developer.mozilla.org/en-US/Add-ons/Code_snippets

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Version:
34 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 35
Iteration:
35.1
Tracking Flags:
Tracking Status
e10s m2+ ---
firefox35 --- verified
firefox36 --- verified

People

(Reporter: alice0775, Assigned: billm)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(5 files)

at first time
(deleted), image/png
Details
input field, no edit control menus
(deleted), image/png
Details
empty area, looks on link menu, no navigation, bookmark menus
(deleted), image/png
Details
correct context menu on empty area
(deleted), image/png
Details
disable-page-menu
(deleted), patch
mconley
: review+
Details | Diff | Splinter Review
Right click on body, on link, on edit field, on selected text. Context menu is broken, sometimes wrong mode. i.e., No Back forward reload stop on body No HTML5 context menu Context menu is not for selected text on selected text Context menu is not for edit on textarea
Summary: [e10s] context menu is broken → [e10s] context menu is completely broken
URL: https://developer.mozilla.org/en-US/A...
Summary: [e10s] context menu is completely broken → [e10s] context menu is completely broken on https://developer.mozilla.org/en-US/Add-ons/Code_snippets
Timestamp: 2014/08/02 10:36:12 Error: NS_ERROR_FAILURE: Failure arg 0 [nsIXULContextMenuBuilder.init] Timestamp: 2014/08/02 10:36:12 Error: gContextMenu is null Source File: chrome://fontinfo/content/showfonts.js Line: 39 Timestamp: 2014/08/02 10:36:12 Error: TypeError: gContextMenu is null Source File: chrome://browser/content/browser.xul Line: 1
Attached image at first time (deleted) —
completely broken
Attached image input field, no edit control menus (deleted) —
Attached image correct context menu on empty area (deleted) —
Good: HTML5 context menus are available on empty area
Attachment #8468284 - Attachment description: input field → input field, no edit control menus
Attachment #8468286 - Attachment description: empty area → empty area, looks on link menu, no navigation, bookmark menus
tracking-e10s: --- → ?
Assignee: nobody → mrbkap
Blocks: old-e10s-m2
tracking-e10s: ? → +
Flags: firefox-backlog+
Flags: firefox-backlog+
This bug should be fixed for the e10s M2 milestone.
tracking-e10s: + → m2+
Assignee: mrbkap → wmccloskey
The problem here is that web pages can put a "contextmenu" attribute on HTML elements. This attribute then refers to a <menu> subtree that we're supposed to display if the user right clicks on the given element or one of its descendants. The way we build this menu isn't e10s-compatible right now. We need to examine the <menu> object in the content process while building up a XUL menu in the parent. And all this happens in C++ right now. The right way to fix this would be to examine the <menu> in a frame script in the child process, turning it into JSON. Then the parent would build the XUL menu from the JSON. I'm guessing that would be a few days of work. However, I'm going to ask that we move this up to M3 or something. It really doesn't seem like M2 material. I'll post a patch that avoids constructing this menu at all in e10s, which at least papers over the problem while losing some functionality.
Attached patch disable-page-menu (deleted) — — Splinter Review
This should be sufficient for M2. I can't imagine many people use these page menus.
Attachment #8488146 - Flags: review?(mconley)
Flags: firefox-backlog+
Filed bug 1066383 to make this work properly.
Flags: qe-verify?
Attachment #8488146 - Flags: review?(mconley) → review+
Bill: is your r+'d disable-page-menu patch ready to land? We're trying to close out our remaining M2 bugs today.
^
Flags: needinfo?(wmccloskey)
https://hg.mozilla.org/mozilla-central/rev/92c22fc0c26b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Iteration: --- → 35.1
Flags: qe-verify? → qe-verify+
QA Contact: jbecerra
I was able to reproduce this issue on Nightly 34.0a1 (2014-08-01) using Windows 7 x64. Verified fixed on Latest Firefox 36.0a1 (2014-11-22) and Latest Firefox 35.0a2 (2014-11-23)(about:config -> browser.tabs.remote.autostar->true) using Windows 7 x64.
Status: RESOLVED → VERIFIED
status-firefox35: --- → verified
status-firefox36: --- → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: