Last modified: 2014-09-20 01:09:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 70431 - WikiEditor loads in different places in the Page namespace depending upon which user preferences are selected
WikiEditor loads in different places in the Page namespace depending upon whi...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ProofreadPage (Other open bugs)
master
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
https://en.wikisource.org/wiki/Page:4...
: javascript
Depends on:
Blocks: edit-toolbar Wikisource
  Show dependency treegraph
 
Reported: 2014-09-05 01:15 UTC by George Orwell III
Modified: 2014-09-20 01:09 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
location loaded with both 'show edit toolbar' and 'enable enhanced editing toolbar' are selected (168.43 KB, image/png)
2014-09-05 01:15 UTC, George Orwell III
Details
location loaded when only 'enable enhanced editing toolbar' is selected (139.33 KB, text/plain)
2014-09-05 01:16 UTC, George Orwell III
Details

Description George Orwell III 2014-09-05 01:15:13 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.
Comment 1 George Orwell III 2014-09-05 01:16:41 UTC
Created attachment 16384 [details]
location loaded when only 'enable enhanced editing toolbar' is selected
Comment 2 Helder 2014-09-08 13:58:32 UTC
We need to check this again once Ie455009df54deecc67707779e9861daf633fc690 is live.
Comment 3 George Orwell III 2014-09-09 20:28:13 UTC
(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.
Comment 4 George Orwell III 2014-09-12 21:24:18 UTC
(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.
Comment 5 George Orwell III 2014-09-20 00:41:04 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links