Closed Bug 100085 Opened 23 years ago Closed 11 years ago

disabled form elements steal events and prevent context menu or dialogs

Categories

(Core :: DOM: Events, defect, P4)

PowerPC
macOS
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.6alpha

People

(Reporter: Brade, Assigned: Brade)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(4 keywords, Whiteboard: EDITORBASE+)

Attachments

(1 file, 1 obsolete file)

I am unable to double-click or contextualMenu-click to bring up properties for 
checkbox.  Is this Mac-specific?
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.
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
*** Bug 98585 has been marked as a duplicate of this bug. ***
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
This looks like a dup of 97870?
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.
Status: NEW → ASSIGNED
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
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
Whiteboard: EDITORBASE → EDITORBASE-
Context menu access to Advanced Edit dialog no longer works in Windows.
This should go to an events person, not brade!
Assignee: brade → joki
Status: ASSIGNED → NEW
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
Whiteboard: EDITORBASE- → EDITORBASE
On second thought, it seems editor:core should address this issue.
Assignee: joki → mjudge
Component: Event Handling → Editor: Core
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
removing EDITORBASE- per meeting
Whiteboard: EDITORBASE → EDITORBASE-
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'
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title></title></head>
<body>
<script language="JavaScript" type="text/javascript">
function test() {
   var pass = document.createElement("p")
   pass.appendChild(document.createTextNode("A click event has fired."))
   document.body.appendChild(pass)
   }
</script>
<form action="javascript:void()">
<p><span onclick="test()"><button>Hello</button><input type='text' name="inputname"
 value='blah' size='18' disabled='disabled' /></span></p>
</form>
</body>
</html>

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020510
Recommend Platform, OS->All based on comment #10.
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future
Attached file testcase (obsolete) —
Keywords: testcase
Priority: -- → P4
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?
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
this needs to be tested against the trunk
Keywords: qawanted
QA Contact: madhur → beppe
Whiteboard: EDITORBASE- → EDITORBASE+
Attached file 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
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.
EDITORBASE+ topembed+ normalization
Keywords: topembed+
Discussed in bug triage.  Can we get status and milestone update please?
Target Milestone: Future → mozilla1.6alpha
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
type=checkbox w/checked
type=file

All select elements


Blocks: 190876
Blocks: 141432
Depends on: 218093
Sorry, I don't know anything about Mozilla bug reporting, but I just encountered this bug in Firefox 2.0.0.14 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
I can verify this bug in FF4b8 on WinXP.

This bug should be for Platform/OS all as suggested by comment 12.
WFM on the latest Nightly, on Ubuntu 13.04 and Mac OSX 10.7.5.
Status: NEW → RESOLVED
Closed: 11 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.