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

NEW
Unassigned

Status

()

defect
P3
major
11 years ago
6 years ago

People

(Reporter: info, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

Reporter

Description

11 years ago
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.
Blocks: 317375
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Another bug is: The controls (textareas, textboxes, buttons - they work) must be doubleclicked to get selected. In Gecko 1.8 everything worked fine.
Reporter

Comment 3

11 years ago
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.1?
Flags: blocking1.9.1?
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.
(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.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Priority: -- → P3
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
OS: Windows Vista → All
Hardware: PC → All

Comment 10

11 years ago
This is basically the same problem that Bug 416766
Putting this on zwol's list.
Assignee: nobody → zweinberg
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.

Comment 14

11 years ago
(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.
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+

Comment 16

11 years ago
See also bug 463685.  Exact same issue, filed sooner.

Updated

11 years ago
Duplicate of this bug: 463685

Updated

9 years ago
Blocks: 424615
I no longer work for Mozilla, I am deassigning myself from bugs I have no intention of working on as a volunteer.
Assignee: zackw → nobody
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

9 years ago
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?

Comment 23

9 years ago
(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

8 years ago
The issue seems to be actual in latest FF.

Does anybody know if any workaround for this exists?

Thanks.

Comment 25

6 years ago
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
You need to log in before you can comment on or make changes to this bug.