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.
*** 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.
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.
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 ?
Context menu access to Advanced Edit dialog no longer works in Windows. This should go to an events person, not brade!
On second thought, it seems editor:core should address this issue.
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.
removing EDITORBASE- per meeting
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?
this needs to be tested against the trunk
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.
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
Discussed in bug triage. Can we get status and milestone update please?
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
Sorry, I don't know anything about Mozilla bug reporting, but I just encountered this bug in Firefox 188.8.131.52 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.
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.
I think this was fixed by bug 816340, right?