416766 - Contextmenu event disabled for some input elements in editor mode

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[Martin Kou]

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).

Comment 1

[Martin Kou]

Attachment: Test case with a radio button, a checkbox and a selection box.

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.

Comment 2

[Laurent Jouanneau]

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 ?

Comment 3

[Samuel Sidler (old account; do not CC)]

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.

Comment 4

[speedo]

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.

Comment 5

[Laurent Jouanneau]

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

Comment 6

[David Henderson]

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?

Comment 7

[Jim Reijers]

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.

Comment 8

[Robert Mark]

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.

Comment 9

[Robert Mark]

(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.

Comment 10

[Jim Reijers]

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

Comment 11

[heid]

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

Comment 12

[Jim Reijers]

Pretty incredible that this glaring bug is still being ignored.

Comment 13

[Michael Blinn]

Bump

Comment 15

[djmaze]

Is someone actually working on this issue?

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

(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?

Comment 17

[(no longer active)]

No, sorry. :(

Comment 18

[thaxy]

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.

Comment 19

[yu]

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.