Last modified: 2010-07-22 12:01:25 UTC
Specifically, this is about a conflict between the new toolbar and wikEd, where '''Bold Text''' is inserted in the edit textarea, when you hit "enter" from the summary field in order to submit. For the WikEd bugreport see the URL.
What browser is this happening in? In FF the toolbar buttons don't work at all, they actually take me to the page in read mode... There's clearly some conflicting things going on here...
This was in Safari 4 (and Chrome 2).
Will check into it...
It also happens in Seamonkey and Firefox 3.5. It is not related to any wikEd event and does not pass the wikEd submit button handler...
wikEd adds the (old and new) toolbar to a toolbar wrapper div (wikEd code line 2229, see http://en.wikipedia.org/wiki/User:Cacycle/wikEd.js). The strange auto-submit after pushing any toolbar button as well as after pushing the enter button from the edit summary disappears when commenting line 2242 (wikEdToolbarWrapper.appendChild(wikEdToolbar);) out.
To make wikEd compatible with the old toolbar wikEd overwrites/redirects the insertTags() function in edit.js to WikEdInsertTags() (line 11837). Is there something similar I can do for the new toolbar? I have played with doing the same with wpTextbox1's .encapsulateSelection to no avail so far.
I have disabled the toolbar wrapping for the new toolbar as a quick temporary fix in wikEd version 0.9.85d.
Small correction: I meant that the insertion of '''Bold text''' when return-submitting from the summary has been temp fixed. As for the wikEd compatibility of the new toolbar: A week ago or so the new toolbar was functional in wikEd as far as I can remember.
Summary changed because this issue is not related to wikiEd. I see this behaviour still at translatewiki.net, running r54150. Using FF 3.5.1 under WinXP.
This was caused by the use of <input type="image" src="" /> tags for toolbar buttons rather than <img src="" /> tags - making the form get confused which button to execute when the user pressed enter. Solved in r54463.
