Tickets :: [#2344] Using HTML composition by default steals focus

6.0.0-beta1

7/14/25

Summary	Using HTML composition by default steals focus
Queue	IMP
Queue Version	HEAD
Type	Bug
State	Duplicate
Priority	1. Low
Owners
Requester	kevin_myer (at) iu13 (dot) org
Created	07/27/2005 (7292 days ago)
Due
Updated	03/28/2007 (6683 days ago)
Assigned
Resolved	03/28/2007 (6683 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

03/28/2007 05:42:40 PM	Chuck Hagenbuch	Comment #7 State ⇒ Duplicate	Reply to this comment
Duplicate of ~~request 1938~~

07/27/2005 06:05:01 PM	Chuck Hagenbuch	Comment #6	Reply to this comment
But whether you wrote it or not, you choose to incorporate it into an existing framework and by using it, it breaks expected behavior. But nevermind. Maybe the work on the WYSIWIG editor will provide a suitable replacement for htmlarea. Its not worth arguing over and I don't have the energy for it anymore anyway. This is why we should just forget about anything not written by us. Apache, MySQl... too much damn variability. Hell, we get stuck with stuff in because of how PHP is written. Sucks to be us.

07/27/2005 04:25:58 PM	kevin_myer (at) iu13 (dot) org	Comment #5	Reply to this comment
See, that's still a bug. You can't just say "well, thats the way the component works", which is what I figured would be the case on this bug. Of course I can, because this component is not provided by us. But whether you wrote it or not, you choose to incorporate it into an existing framework and by using it, it breaks expected behavior. But nevermind. Maybe the work on the WYSIWIG editor will provide a suitable replacement for htmlarea. Its not worth arguing over and I don't have the energy for it anymore anyway. Kevin

07/27/2005 03:15:19 PM	Jan Schneider	Comment #4	Reply to this comment
See, that's still a bug. You can't just say "well, thats the way the component works", which is what I figured would be the case on this bug. Of course I can, because this component is not provided by us. There are potential fixes available: http://www.htmlarea.com/forum/htmlArea_3_(beta)_C4/htmlArea_2_&_3_archive_(read_only)_C4/htmlArea_v3.0_-_Discussion_F14/HTMLarea_steals_focus_P35051/ Although that may break other things, judging from the post. Yup. Couldn't you use javascript to steal the focus back to the first form element? No, because the editor is initialized after the page and component loading, and there is no callback hook available afaik after the loading is completed.

07/27/2005 03:06:23 PM	kevin_myer (at) iu13 (dot) org	Comment #3	Reply to this comment
See, that's still a bug. You can't just say "well, thats the way the component works", which is what I figured would be the case on this bug. It provides a very inconsistent user interface, and little things like the location of a cursor drive users nuts, especially since most users type an address first, then type the message. There are potential fixes available: http://www.htmlarea.com/forum/htmlArea_3_(beta)_C4/htmlArea_2_&_3_archive_(read_only)_C4/htmlArea_v3.0_-_Discussion_F14/HTMLarea_steals_focus_P35051/ Although that may break other things, judging from the post. Couldn't you use javascript to steal the focus back to the first form element?

07/27/2005 01:22:11 PM	Jan Schneider	Comment #2 State ⇒ Not A Bug	Reply to this comment
This happens in the WYSIWYG editor and is nothing we can change about.

07/27/2005 12:39:58 PM	kevin_myer (at) iu13 (dot) org	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ Using HTML composition by default steals focus Queue ⇒ IMP State ⇒ Unconfirmed	Reply to this comment
If you use plaintext composition by default, when you invoke the compose screen, cursor focus is on the To: field. If you use HTML composition by default, when you invoke the compose screen, cursor focus is in the Text field, forcing the user to click back on the To: field to address the message. This behavior occurs in both IE and Firefox.