446670 - Unable to select Checkbox, Radio and Select form elements in designMode=true in FireFox 3.x

Status: NEW

(Core :: Layout, defect, P3)

Description

[E-VISION International, s.r.o.]

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)

Comment 1

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Robert Stopp (textrinum)]

Attachment: Testcase shows: Selection isn't updated for Selects, Radios and Checkboxes and Clicks, Mousedowns/ ups/ moves are not recognized in Gecko 1.9 for them.

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

Comment 3

[E-VISION International, s.r.o.]

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.

Comment 4

[Robert Stopp (textrinum)]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What's a regression range for this bug?

Comment 6

[Robert Stopp (textrinum)]

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

Comment 7

[Ria Klaassen (not reading all bugmail)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 9

[Daniel Holbert [:dholbert]]

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

Comment 10

[Alfonso Martinez]

This is basically the same problem that Bug 416766

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Putting this on zwol's list.

Comment 12

[Zack Weinberg (:zwol)]

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?

Comment 13

[Martijn Wargers (dead)]

Attachment: testcase, without logging events

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.

Comment 14

[Matti Järvinen]

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

Comment 15

[Robert Stopp (textrinum)]

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

Comment 16

[Marc Cohen]

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

Comment 18

[Zack Weinberg (:zwol)]

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

Comment 19

[Robert Stopp (textrinum)]

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.

Comment 20

[(no longer active)]

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?

Comment 21

[Boris Zbarsky [:bzbarsky]]

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?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 23

[(no longer active)]

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

Comment 24

[Ivan Babkin]

The issue seems to be actual in latest FF.

Does anybody know if any workaround for this exists?

Thanks.

Comment 25

[Blagoja]

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

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 27

[Daniel Holbert [:dholbert]]

I think this issue still exists, if I'm understanding correctly.

STR for the issue that I'm seeing when retesting with Nightly 115:

1. Load https://bug446670.bmoattachments.org/attachment.cgi?id=337902
2. Click the checkbox, radio button, or select dropdown menu.

EXPECTED RESULTS:
"click on [...form control type...]" should appear in the logging area on the left.

ACTUAL RESULTS:
No logging appears. (For select dropdown, we do log Focus on "SELECT", but we don't log anything for the click.

We do log clicks for the other form widgets in the testcase, so there does seem to be a strange discrepancy of some sort here.

Anyway -- triaging as S3. Also updating the URL field to point to the attached testcase, since the URL that we had there is now 404.