Bug 12257
| Summary: | FCKeditor: Form fields are enabled in the editing area | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | webkit |
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | michael.vm |
| Priority: | P2 | ||
| Version: | 420+ | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.fckeditor.net/nightly/browsers_test.html | ||
| Bug Depends on: | |||
| Bug Blocks: | 9915 | ||
webkit
All form fields created inside the editor are enabled during editing. So, one can check checkboxes, insert text on fields, open combo boxes, or even click on buttons.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
This behavior does disagree with Firefox, but I can see some applications wanting this current behavior.
You can control this sort of thing by adding temporary onClick handlers (using addEventListener) and calling event.preventDefault from within those listeners. You could also make your own custom "control selection" (like mentioned in bug 12250) using this functionality if you so desired.
webkit
(In reply to comment #1)
We are already doing "click", "mousedown" and "mouseup" events handling to try to avoid this thing. We are able to not make them active (except for select fields, which always open), but no lucky on making them selectable. You can test it in the above URL.
Making a custom control selection instead, other than being a massive job in JavaScript, would not solve problems like drag and drop or copy/cut. Also, as explained above, it doesn't work for all kinds of fields.
To conclude, I think that it would be weird to have applications that need active form fields inside an editable document. Even if needed, those would be a great minority, and would certainly be compatible with Safari only at this point.