The editing toolbar (or another new component) seems to set focus on the textarea (or a related element) even if the standard textarea is hidden and the wikEd editing iframe is in place. Any focusing should only be done if the textarea is not hidden (style.display != 'none').
Version: unspecified
Severity: normal
Focusing happens shortly after page load and after pushing the toolbar edit buttons. See also Bug 20134.
The toolbar also steals the focus after clicking any wikEd button! People are already complaining about this issue on the wikEd bug page and it is a major compatibility problem.
Would it be very difficult to hook into and block the textarea focus event? Like:
$('#wpTextbox1').focus( function(e) {
e.preventDefault(); // Don't actually focus // Maybe do more stuff here
});
As for focusing in general, I think it would be a cleaner solution to manage this in the toolbar code, e.g. as a wrapper for .focus() that checks if the focus target (the textbox) is visible (.display!="none").
For the second issue: For compatibility reasons with gadgets, the toolbar must not add any events to buttons other than its own.
(In reply to comment #4)
As for focusing in general, I think it would be a cleaner solution to manage
this in the toolbar code, e.g. as a wrapper for .focus() that checks if the
focus target (the textbox) is visible (.display!="none").
That sounds like a good idea.
For the second issue: For compatibility reasons with gadgets, the toolbar must
not add any events to buttons other than its own.
Could you explain how this is relevant? I don't see it.
The toolbar seems to add events to buttons that do not belong to it (like all wikEd buttons and probably also of other gadgets and user scripts). The toolbar must only add events to its own buttons.
wikEd rearranges the toolbar as well as the textarea into div wrappers. The toolbar might need a more robust method to determine which buttons belong to itself and not to other application.
(In reply to comment #6)
The toolbar seems to add events to buttons that do not belong to it (like all
wikEd buttons and probably also of other gadgets and user scripts). The toolbar
must only add events to its own buttons.
(In reply to comment #7)
wikEd rearranges the toolbar as well as the textarea into div wrappers. The
toolbar might need a more robust method to determine which buttons belong to
itself and not to other application.
The toolbar only adds events to buttons as it adds them, it doesn't do anything like 'add this event to all buttons that are children of children of this div'. I'll play around with wikEd a bit later and I'll try to figure out what's going on.
Thanks for looking into this. If you click any wikEd button, the textarea (or something else) gets focused as indicated by a giant blinking caret on the right side of the edit area (supposedly the hidden textarea or an element focused instead). Surprisingly, this behaviour disappears after pushing the local preview or the local diff buttons next to the submit and preview buttons. The problem happens only with the enhanced toolbar running. I have just checked the wikEd focusing code and it looks robust to me.
I cannot verify this because the enhanced toolbar has disappeared! It is no longer available from the preferences or by clicking the beta test link.
(In reply to comment #11)
I cannot verify this because the enhanced toolbar has disappeared! It is no
longer available from the preferences or by clicking the beta test link.
It was temporarily disabled because it blew up on IE8 (see bug 20668); it's back now.
The problem still exists. You can replicate it by pushing the wikEd regexp button. It can also be seen after pushing the standard Submit/Preview/Diff buttons before the new page loads.
(In reply to comment #13)
The problem still exists. You can replicate it by pushing the wikEd regexp
button.
That behaves the same way with and without the toolbar for me.
It can also be seen after pushing the standard Submit/Preview/Diff
buttons before the new page loads.
What do you mean by "before the new page loads"?
With the enhanced toolbar enabled, pushing the wikEd regexp button in Firefox 3.5.3 focuses the document. This lets the caret start blinking wherever it was positioned before. For me the default position is under the edit are, right before the "Content that violates any copyrights will be deleted..." element. This focusing does not happen with the enhanced toolbar disabled.
The toolbar should not focus the document or any other document element when wikEd runs, especially (but not restricted to) after pushing buttons not belonging to it. wikEd sets the focus to its own iframe document after processing wikEd buttons.
Re "before the new page loads": after pushing the submit or preview buttons and before the current page disappears and the new page loads, you can see the exact same focusing phenomenon for a moment.
(In reply to comment #15)
With the enhanced toolbar enabled, pushing the wikEd regexp button in Firefox
3.5.3 focuses the document. This lets the caret start blinking wherever it was
positioned before. For me the default position is under the edit are, right
before the "Content that violates any copyrights will be deleted..." element.
This focusing does not happen with the enhanced toolbar disabled.
It does for me:
(In reply to comment #17)
I am not sure what that means or implicates :-)
$j(document).focus(function(e){console.log(e);}); means: whenever the document received a focus event, log the event object to the Firebug console. Upon clicking the regex buttons, two log lines corresponding to focus event objects appear in the console, which means that clicking the regex button somehow causes a focus on the document even though the enhanced toolbar isn't enabled.
Note that this requires viewing the edit form with Vector and having EditWarning enabled, otherwise jQuery won't be loaded and $j won't be defined.
At this time, we are not planning on dedicating resources to attaining/maintaining compatibility with the wikEd gadget.