Last modified: 2014-09-20 01:09:10 UTC
Created attachment 16383 [details]
location loaded with both 'show edit toolbar' and 'enable enhanced editing toolbar' are selected
On Wikisource, when editing in the Page: namespace, ....
1.) if both 'show edit toolbar' and 'enable enhanced editing toolbar' are selected in a user's preferences, WikiEditor loads above the header textarea.
2.) If ONLY 'enable enhanced editing toolbar' is selected in a User's preferences, WikiEditor loads below the header textarea but above the body textarea.
The WikiEditor toolbar should consistently load in the same place regardless of User preferences selected (above any & all textarea boxes or, as in the attached depiction shows, above the header field IF/WHEN that is also enabled as the default [e.g. showing/hiding header & footer fields is also a User preference on Wikisource]). In short, WikiEditor should always be directly atop the topmost editable textarea.
There is no discernable difference in actual functionality between the two User preference conditions other than a momentary appearance of the 'classic' toolbar before being replaced by the WikiEditor toolbar when condition 1.) is true.
Created attachment 16384 [details]
location loaded when only 'enable enhanced editing toolbar' is selected
We need to check this again once Ie455009df54deecc67707779e9861daf633fc690 is live.
(In reply to Helder from comment #2)
> We need to check this again once Ie455009df54deecc67707779e9861daf633fc690
> is live.
If that was suppose to be part of today's 1.24wmf20 roll-out, I don't see any change - same behavior as previously outlined.
What's worse - I'm seeing the CharInsert extension's toolbar load above the WikiEditor toolbar [only] in the Page: namespace [only] when both User: preferences are enabled now too (Win 8.1/IE11) whereas before the core update, it loaded according to the related setting(s) in my User: .js file.
This new behavior might somehow be due to a poor attempt to legitimize that CharInsert toolbar position as a valid option in the CharInsert gadget .js file on my part however.
(In reply to George Orwell III from comment #3)
> If that was suppose to be part of today's 1.24wmf20 roll-out, I don't see
> any change - same behavior as previously outlined.
Hmmm... I guess the patch will be coming next Tuesday in 1.24wmf21 instead. It seems to work on test2.wikipedia.org however. See...
... against the mentioned User preference setting for example. The test-bed doesn't have the CharInsert gadget installed so that quirk still needs to be verified/eliminated.
While a separate issue with the positioning of the CharInsert toolbar mentioned in comment #3 remains, the specifically reported problem has been resolved. Not sure if the fix is was a result in part thanks to....
https://gerrit.wikimedia.org/r/159043 or https://gerrit.wikimedia.org/r/115205
... or both, but 'fixed is fixed' so I'm closing this bug.
If the local core CharInsert .js script is eliminated as a possible cause for the remaining toolbar positioning quirk in the Page: namespace, a new bugzilla will most likely be filed to address that issue.