User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 The contextmenu event is disabled for checkboxes, radio buttons and selection boxes when editor mode is activated. This is making it impossible for context menus to work with these elements in editor mode. Reproducible: Always Steps to Reproduce: 1. Draw a few checkboxes, radio buttons, or selection boxes in an HTML file. 2. Attach context menu events to them. 3. Activate editor mode by document.designMode = 'on'. 4. Right click on the elements created in step 1. Actual Results: The context menu handlers attached in step 2 are not called. Expected Results: The context menu handlers should be called. This is causing the bug #703 in FCKeditor (https://dev.fckeditor.net/ticket/703).

Right clicking on the input elements in Firefox produces does not trigger the alert box. Doing the same thing on IE or Safari would trigger the alert box.

I confirm the bug. I think this is a regression since the landing of Bug 237964 . Is it related to the style -moz-user-modify set to "read-write" in gecko 1.9, instead of read-only in gecko 1.8 ?

Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.

In Firefox 2.x and 3.x it is not possible to select and check-in/out the checkbox input elements inside the editable DIV / IFRAME elements. Here is an example: <div style="border: 1px solid red;width: 500px;height:300px;overflow: scroll;" id="editableDIV" contenteditable="true"> <input type="checkbox" /> </div> Put this DIV in a standard HTML page and load it in Firefox -> click on the checkbox and you will see that it could not be checked. The context menu did not show as well.

@speedo : you cannot check a checkbox in an editing mode. This is not a bug.

Does anyone know of a workaround for this in the current version? It is currently causing a fair amount of pain - we're using an editor component that correctly lets us insert form elements, but this bug precludes our users from making any changes to the elements. For example we allow the insertion of a select with user-defined options in it. if the user makes a mistake, the only recourse is to delete the select and re-insert it (re-adding the correct options in the process). Give the fact the elements are completely unselectable, it is also impossible to click on the form element to select it and operate on the selection. Any ideas?

I don't understand why this bug isn't being worked on. After all, it cripples most online WYSIWYG editors. Is there at least some sort of workaround, because this is just unacceptable.

I agree with Jim. I've been coming back to this ticket for almost a year now and there has been no progress. Most of my clients have had to switch to Internet Explorer because of this bug. I really wish there were something I would be able to help with to get the ball rolling.

(In reply to comment #5) > @speedo : you cannot check a checkbox in an editing mode. This is not a bug. This is not a problem with changing the form element 'state' when selected in editing mode. It's a problem with the element itself being unselectable.

At least I managed to write a patch plugin for FCKeditor. For those interested: http://dev.fckeditor.net/attachment/ticket/703/contextMenuFix.zip

That's no patch but a workaround. Please fix the main issue :-/

Pretty incredible that this glaring bug is still being ignored.

Bump

Is someone actually working on this issue?

(In reply to djmaze from comment #15) > Is someone actually working on this issue? I don't think so. Ehsan did you get anywhere with it?

No, sorry. :(

Hi, 2016 is here and this is still a pain in the .... Using an Html Editor, I shall now redirect all my users (1000+) to Chrome because of this stupid issue. Veryvery sad.

Hi, I created a patch: diff --git a/dom/html/nsHTMLDocument.cpp b/dom/html/nsHTMLDocument.cpp index 00a1e6d..573d4e7 100644 --- a/dom/html/nsHTMLDocument.cpp +++ b/dom/html/nsHTMLDocument.cpp @@ -2860,6 +2860,16 @@ nsHTMLDocument::EditingStateChanged() // the document for compatibility reasons. if (designMode && oldState == eOff) { editor->BeginningOfDocument(); + nsCOMPtr<nsIContentViewer> cv; + docshell->GetContentViewer(getter_AddRefs(cv)); + if (cv) { + bool isSticky; + cv->GetSticky(&isSticky); + cv->SetSticky(false); + cv->Hide(); + cv->Show(); + cv->SetSticky(isSticky); + } } if (putOffToRemoveScriptBlockerUntilModifyingEditingState) { It works fine for me, I only test it on mips platform (Loongson 3A cpu), can any body help to review this code? Thank you.