User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Clicking on form elements (checkbox, radio and select) in designMode does not select these elements and also there are no other events called (mousedown, mouseup, ...). The only way to get these events called was to remove this from /res/contentEditable.css: /* XXX Still need a better way of blocking other events to these widgets */ select:-moz-read-write, :-moz-read-write > input[disabled], :-moz-read-write > input[type="checkbox"], :-moz-read-write > input[type="radio"], :-moz-read-write > input[type="file"], input[contenteditable="true"][disabled], input[contenteditable="true"][type="checkbox"], input[contenteditable="true"][type="radio"], input[contenteditable="true"][type="file"] { -moz-user-select: all !important; -moz-user-input: none !important; -moz-user-focus: none !important; } After this events were called, but the elements did not get selected on click. Reproducible: Always Steps to Reproduce: 1.use designMode on iframe with checkbox, radio and select form elements inside 2.click, doubleclick or rightclick on any of these elements - it doesn't do anything (but on FF2 it selects these elements - it worked great on FireFox 2.x) Actual Results: click, doubleclick or rightclick on any of form elements (checkbox, radio and select) doesn't do anything Expected Results: elements should change state to selected (as it worked in FireFox 2.x). Also other form elements (text, textarea, buttons) should be selectable on one click (in FireFox 3 there is now a doubleclick needed)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 When I click on the selectbox, it selects, but the checkbox and the radio button don't select. This regressed on 25 Jan 2006 from bug 317375.

Another bug is: The controls (textareas, textboxes, buttons - they work) must be doubleclicked to get selected. In Gecko 1.8 everything worked fine.

Wow - thanks - after about 2 months I see some replies to this bug. We hope you will fix this bug in next release, because we are still recommending older 2.x versions of FireFox for our customers now. I personally like 3.x version (i't much more faster), but this bug is limiting our software, so we cannot recommend this release.

(In reply to comment #3) > Wow - thanks - after about 2 months I see some replies to this bug. We hope you > will fix this bug in next release... Sorry I can't fix this problem because I'm not a Mozilla developer. But I can send you a workaround if you asks for progress or vote on bug 399046 ;-)! It seems that "-moz-user-input" for these controls has changed his behaviour in Gecko 1.9 and designmode. They are unselectable and unwatchable with this rule set to none. You must ask someone of the Mozilla Crew a bit louder (perhaps CC'ing him/her to this bug).

What's a regression range for this bug?

(In reply to comment #5) > What's a regression range for this bug? If the control is selected by script, there is no visual feedback of the selection. Additional: (no regression) drag and drop isn't possible.

Regression range of Robert's testcase (the log that suddenly changed) is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1182998100&maxdate=1183002779 and the broken selection COLOR of at least the radio button and checkbox is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-01-25+16%3A00&maxdate=2006-01-26+10%3A00

(In reply to comment #0) > Clicking on form elements (checkbox, radio and select) in designMode does not > select these elements and also there are no other events called (mousedown, > mouseup, ...). What should happen when clicking on form controls while editing isn't obvious to me, although I suppose selection does seem like a reasonable option. It definitely seems like a bug that events aren't getting through, though.

I can reproduce this on today's nightly: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081009 Minefield/3.1b2pre OS/Hardware --> All

This is basically the same problem that Bug 416766

Putting this on zwol's list.

I'm looking at this but it's hard to tell what's actually supposed to happen. Does this test case display the desired behavior if opened in Firefox 2? If not, could someone please spell out in great detail what is supposed to happen (both visually and in terms of events) when each of the form controls is clicked? Double-clicked? Right-clicked?

This one is testable in IE. I think what IE does, is at least more useful. It allows resizing the various form elements and you can check the input checkbox.

(In reply to comment #12) > I'm looking at this but it's hard to tell what's actually supposed to happen. > Does this test case display the desired behavior if opened in Firefox 2? If > not, could someone please spell out in great detail what is supposed to happen > (both visually and in terms of events) when each of the form controls is > clicked? Double-clicked? Right-clicked? " Clicking on form elements (checkbox, radio and select) in _designMode_ does not select these elements and also there are no other events called (mousedown, mouseup, ...). " emphasis mine. This is about area defined content-editable not firing events and not selecting mentioned elements. I believe that atleast events should be called on elements when clicked. This is a big deal since every HTML + javascript WYSIWYG editor which can handle forms and form inputs are currently broken on FF since no event can be traced to mentioned form inputs.

- a selected form control (single-clicked) should have a colored background - DOMActivate (pressed state) is not necessary on buttons - drag and drop should be possible (https://bugzilla.mozilla.org/attachment.cgi?id=338300 (Testcase from another,fixed, bug 454986 )) I'm not with Martin (In reply to comment #13) > I think what IE does, is at least more useful. It allows resizing the various > form elements and you can check the input checkbox. I think this is up to the implementer to provide a UI for these things. Or at least it should be switchable (https://bugzilla.mozilla.org/show_bug.cgi?id=399046#c42). (In reply to comment #12) > Does this test case display the desired behavior if opened in Firefox 2? Yes, mostly. http://sourceforge.net/project/showfiles.php?group_id=151265&package_id=283201 A bit off-topic: Right-clicking on buttons outside designmode is also without effect.

See also bug 463685. Exact same issue, filed sooner.

I no longer work for Mozilla, I am deassigning myself from bugs I have no intention of working on as a volunteer.

Can we expect progress in this issue? Why is it not possible to override some rules for a better handling in designmode for implementors? In earlier versions it was possible making hidden inputs visible, selectable and editable, now impossible too.

Would it be possible to to add a DOMActivate event handler to the editable root of the document to cancel that event for all editable elements, and stop using the hack mentioned in comment 0?

Possibly... But some of the things being blocked are not DOMActivate, are they? e.g. isn't one of the goals to prevent an editable combobox from dropping down when clicked?

Note, I assume and hope we'll get rid of DOMActivate reasonable soon unless there are some real use cases for it. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10899 What all things need to be blocked? Could we just check if the form control is in contentEditable in those cases?

(In reply to comment #22) > Note, I assume and hope we'll get rid of DOMActivate reasonable soon > unless there are some real use cases for it. > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10899 OK, then I guess we wouldn't want to use it here. > What all things need to be blocked? Basically form control interactions which manipulate their presentation (such as checking a checkbox), underlying value (such as toggling the checkbox value when clicked) and UI interactions (such as showing a drop-down for comboboxes). > Could we just > check if the form control is in contentEditable in those cases? If there isn't a central place to control the above behaviors, then I think that would be our only choice.

The issue seems to be actual in latest FF. Does anybody know if any workaround for this exists? Thanks.

Same issue on FF 19.0.2. What happened FF was one of the most developer friendly browsers. Please anyone with the solution. I have User Control with dynamically generated radio buttons but can't click on them in FF. Thanks in advance