disabled form elements steal events and prevent context menu or dialogs




DOM: Events
16 years ago
4 years ago


(Reporter: Kathleen Brade, Assigned: Kathleen Brade)


(Depends on: 1 bug, Blocks: 1 bug, 4 keywords)

Mac OS X
helpwanted, pp, testcase, topembed+
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: EDITORBASE+)


(1 attachment, 1 obsolete attachment)

3.41 KB, text/html


16 years ago
I am unable to double-click or contextualMenu-click to bring up properties for 
checkbox.  Is this Mac-specific?

Comment 1

16 years ago
The right-button click to bring up context menu works in Windows, but double
click doesn't. Sounds like an events problem -- the input widget is probably
stealing the event.

Comment 2

16 years ago
Looks like the same problem occurs for "input" and "select" elements as well.
Summary: unable to double-click checkbox to bring up properties → unable to double-click form elements to bring up properties

Comment 3

16 years ago
*** Bug 98585 has been marked as a duplicate of this bug. ***

Comment 4

16 years ago
In particular for a plain <input> or a <textarea>,
double- or triple-clicking erroneously selects the text in the textarea.
I've just upgraded to build 2001091703 and <select> now displays properly.
[This means that I can now write a properties dialog for it.]
However I can no longer double-click it!
Changing Platform/OS to All/All.
OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 5

16 years ago
This looks like a dup of 97870?

Comment 6

16 years ago
This bug should be for the context menu bug which is specific to Macintosh.  It 
may or may not be a similar problem to bug #97870.
Depends on: 97870
Keywords: pp
OS: All → Mac System 9.x
Hardware: All → Macintosh
Summary: unable to double-click form elements to bring up properties → unable to control-click form elements to bring up context menu

Comment 7

16 years ago
Joki--this is one of the bugs we've been discussing...
see also #97870
Joki--do I need to file a bug for your issues or should I just reassign one or 
both of these or ?
Whiteboard: EDITORBASE


16 years ago

Comment 8

16 years ago
Context menu access to Advanced Edit dialog no longer works in Windows.
This should go to an events person, not brade!
Assignee: brade → joki
Component: Editor: Composer → Event Handling
QA Contact: sujay → madhur
Summary: unable to control-click form elements to bring up context menu → form elements steal events and prevent you from to bringing up context menu or dialogs

Comment 9

16 years ago
On second thought, it seems editor:core should address this issue.
Assignee: joki → mjudge
Component: Event Handling → Editor: Core

Comment 10

16 years ago
Please don't reassign my bugs when you don't fully understand the bug.

Having researched this bug and discussed it with Joki, the problem is with
disabled form elements not dispatching the events as expected.  The editor
doesn't see the event because the event propagation (incorrectly) stops.  Tom
thinks we might be able to block dispatch to the element itself (which would
take some work) so the event could propagate but there may be some focus issues
which appear.  Originally, the concern had to do with script handlers within
content (at least that is what Tom thinks caused the original implementation to
work as it does).

Joki--please correct/extend on any of the above.
Assignee: mjudge → brade
Component: Editor: Core → DOM Events

Comment 11

16 years ago
removing EDITORBASE- per meeting


16 years ago
Target Milestone: --- → mozilla1.1
brade:  I'm seeing something very similar to this via
http://freewarejava.com/ubb/Forum1/HTML/025614.html .

Here's my test case:

<?xml version='1.0' ?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN'
<html xmlns='http://www.w3.org/1999/xhtml'>
<script language="JavaScript" type="text/javascript">
function test() {
   var pass = document.createElement("p")
   pass.appendChild(document.createTextNode("A click event has fired."))
<form action="javascript:void()">
<p><span onclick="test()"><button>Hello</button><input type='text' name="inputname"
 value='blah' size='18' disabled='disabled' /></span></p>

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020510
Recommend Platform, OS->All based on comment #10.


15 years ago
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future

Comment 13

15 years ago
Created attachment 108558 [details]


15 years ago
Keywords: testcase
Priority: -- → P4

Comment 14

15 years ago
If the editor adds capturing mouse event listeners that call
event.stopPropogation will that block dispatch to the element sufficiently so
that editor can use CSS or whatever is necessary to enable event dispatch even
to disabled elements?


15 years ago
OS: Mac System 9.x → MacOS X
Summary: form elements steal events and prevent you from to bringing up context menu or dialogs → disabled form elements steal events and prevent context menu or dialogs

Comment 15

15 years ago
this needs to be tested against the trunk
Keywords: qawanted
QA Contact: madhur → beppe

Comment 16

15 years ago
Created attachment 115776 [details]
complete test case

Yes, some form elements do not permit the properties dialog to be rendered. I
am attaching a more comprehensive test case.
Attachment #108558 - Attachment is obsolete: true

Comment 17

15 years ago
If I add -moz-user-focus: ignore; and -moz-user-input: disabled; styles to
forms.css and remove the disabled checks in content then there are still a few
issues but it mostly works. Perhaps content needs to check for another CSS style
e.g. -moz-user-modify which doesn't currently appear to be used.
Normal input: normal focus, enabled input, writable
Read only input: normal focus, enabled input, read only
Disabled input: ignore focus, disabled input, read only
Edit mode: ignore focus, enabled input, read only
CC'ing jst for ideas.

Comment 18

15 years ago
EDITORBASE+ topembed+ normalization
Keywords: topembed+

Comment 19

14 years ago
Discussed in bug triage.  Can we get status and milestone update please?


14 years ago
Target Milestone: Future → mozilla1.6alpha

Comment 20

14 years ago
Using the Macho build (2003-05-07-03), I open the attached test case in Composer
and control-clicked on each element to see if a contextual menu would appear.
Here are the elements that didn't display a contextual menu for me:

type=checkbox w/checked

All select elements


14 years ago
Blocks: 190876


12 years ago
Blocks: 141432


12 years ago
Depends on: 218093

Comment 21

9 years ago
Sorry, I don't know anything about Mozilla bug reporting, but I just encountered this bug in Firefox and in the just-released Firefox 3.0.

Setting the "disabled" property of a form element makes it invisible to scripting, as if the events never occurred. In addition, the events don't bubble-up the DOM tree, so it's impossible to tell (at any level of the tree) whether a user attempted to interact with a disabled form element or not.

I just wanted to make sure this bug is still on the radar, since it seems quite old.
QA Contact: rubydoo123 → events

Comment 22

7 years ago
I can verify this bug in FF4b8 on WinXP.

This bug should be for Platform/OS all as suggested by comment 12.

Comment 23

4 years ago
WFM on the latest Nightly, on Ubuntu 13.04 and Mac OSX 10.7.5.
Last Resolved: 4 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
I think this was fixed by bug 816340, right?
sounds right.
You need to log in before you can comment on or make changes to this bug.