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)
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)
3.41 KB,
text/html
|
Details |
I am unable to double-click or contextualMenu-click to bring up properties for checkbox. Is this Mac-specific?
Comment 1•23 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•23 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 4•23 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•23 years ago
|
||
This looks like a dup of 97870?
Assignee | ||
Comment 6•23 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.
Assignee | ||
Comment 7•23 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
Assignee | ||
Updated•23 years ago
|
Whiteboard: EDITORBASE → EDITORBASE-
Comment 8•23 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
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
Comment 9•23 years ago
|
||
On second thought, it seems editor:core should address this issue.
Assignee: joki → mjudge
Component: Event Handling → Editor: Core
Assignee | ||
Comment 10•23 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
Assignee | ||
Comment 11•23 years ago
|
||
removing EDITORBASE- per meeting
Whiteboard: EDITORBASE → EDITORBASE-
Assignee | ||
Updated•22 years ago
|
Target Milestone: --- → mozilla1.1
Comment 12•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future
Comment 13•22 years ago
|
||
Comment 14•22 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?
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•21 years ago
|
||
this needs to be tested against the trunk
Comment 16•21 years ago
|
||
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•21 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 19•21 years ago
|
||
Discussed in bug triage. Can we get status and milestone update please?
Updated•21 years ago
|
Target Milestone: Future → mozilla1.6alpha
Comment 20•21 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 type=checkbox w/checked type=file All select elements
Comment 21•16 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: rubydoo123 → events
Comment 22•13 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•11 years ago
|
||
WFM on the latest Nightly, on Ubuntu 13.04 and Mac OSX 10.7.5.
Comment 24•11 years ago
|
||
I think this was fixed by bug 816340, right?
Comment 25•11 years ago
|
||
sounds right.
You need to log in
before you can comment on or make changes to this bug.
Description
•