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. > > >>SNIP<< Hmmm... I guess the patch will be coming next Tuesday in 1.24wmf21 instead. It seems to work on test2.wikipedia.org however. See... https://test2.wikipedia.org/s/2jf ... 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.
