Last modified: 2013-04-22 16:33:42 UTC
the problem is intermittent, and so far i could only reproduce it in hebrew wikipedia ( http://he.wikipedia.org ), but i doubt it has anything to do with RTL. DESCRIPTION preparation * select "enhanced editing toolbar" in preferences, * enter "edit" state for a SHORT article long enough to have scrollbar in the editor, but not too long. try for something where the whole thing is no more than 3-4 "pgdn" from top to bottom (??) * open the "Advance" menu * grab the edge of browser, and narrow it to the point the toolbar takes two lines, i.e., some of the buttons drop to a second line. now we can reporduce. as mentioned, the problem is intermittent, so reproduction depends on some luck. you may want to try different machines (faster vs. slower etc.), different connection speed (timing seems to be an issue - there is some race condition going on) or other variables. the problem have been observed so far on FF and chrome, on win-7 and kubuntu-10.04 * at this point, "refresh", "super refresh" (i.e. shift-whatever on your browser) etc. reproduction (remember - the "advance" menu is open and occupies 2 lines of buttons) hit "refresh", shift-refresh, <ctrl> refresh etc. if you are lucky, sooner or later the top of the textarea hides behind the toolbar. if you reproduced, note that collapsing and reopening "advance" cures the problem - the textarea will have the correct size after closing and opening "advance". tried to get similar results with other menus ("help", "special characters") - could not repro. tried to get the same effect in en.wikipedia.org - failed. nl.wikipedia.org - failed.
Screenshots would probably be helpful here. You can attach them to this bug report or upload them to mediawiki.org. It's also kind of unclear to me whether this happens with any article or only particular articles. If there are particular articles where this problem occurs (or is more likely to occur), links would be nice.
Created attachment 8211 [details] screenshot of bug - top of textarea covered by toolbar note that the top of the scrollbar (and the top of the textarea with it) is hidden below the toolbar. peace.
additional info: it is unclear whether this happens with specific pages or any page. so far i was only able to observe it for articles long enough to have a scrollbar, but not with very long articles - it's easiest to repro if the scrollbar itself is no less than one third of the height of the textarea. here is a link to the article in the screenshot: http://he.wikipedia.org/w/index.php?title=%D7%AA%D7%99%D7%90%D7%98%D7%A8%D7%95%D7%9F_%D7%AA%D7%90%D7%99%D7%A8&action=edit peace.
also: i had most luck so far reproducing with chrome (10.0.648.82 beta), but initial report came from a firefox 3.6.13 user, and i was also able to repro with same. peace.
*** Bug 27804 has been marked as a duplicate of this bug. ***
The problem is similar to one I once had while writing some toolbar customization code; in fact, there is some toolbar customization in http://he.wikipedia.org/wiki/MediaWiki:Edittoolbar.js, which is imported in Common.js. The reason it's hard to reproduce is that this may depends on the exact time when the toolbar customization code is called. But it's easy to reproduce the bug by adding things after the page is completely loaded (for example, by using a javascript console to add enough buttons and group to make the toolbar grow vertically). The fact is that the code of addToToolbar (in jquery.wikiEditor.toolbar.js) only bothers of changing the height of the toolbar's "div.sections" only when a new section is added, and not when groups or buttons are added to existing sections. In fact the problem is not going to happen if a new section is created with all groups and buttons in bulk, in a single call to the addToToolbar function. While adding things in bulk is better (and I think it's going to solve the problem in this particular instance), adding objects to existing sections is allowed (and it's the documented way: http://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization), so a solution is needed.
Created attachment 8479 [details] Proposed patch The proposed patch (rooted in the WikiEditor extension) moves the code to resize div.sections in a place where it is always executed (and not just when sections are added). If only sections are added, uses the old way with $.animate() to change the height; otherwise, just changes the height without any animation.
(In reply to comment #7) > Created attachment 8479 [details] > Proposed patch > > The proposed patch (rooted in the WikiEditor extension) moves the code to > resize div.sections in a place where it is always executed (and not just when > sections are added). If only sections are added, uses the old way with > $.animate() to change the height; otherwise, just changes the height without > any animation. Thanks for figuring out what the problem was and providing a patch. I applied it in r87979
Same issue reappeared in enwiki: some icons (for me it's the newline and "table dialog" buttons) leak from the toolbar into the textarea. Reproduction: # enwiki, using Vector and "Enable enhanced editing toolbar". make sure JS and cookies enabled. # open random article for editing # unfold "Advanced" tab on editor toolbar. # While "Advanced" is still open, close the editing window (you can hit "save" for null edit) # open another (or same) article. # note that some of the buttons from advanced toolbar leak into textarea # repeat the last two steps until it actually happens. if you fail to reproduce, try another browser, or faster or slower link: this seems to be some race condition of loading and activating different JS scripts, so the precise timing seems to affect it. I was able to reproduce only with chrome (25.0.1364.172 m), but other users experienced this on other browsers (the screenshot seems to be from safari on mac, but i might be wrong here). peace. Screenshot: [[File:Screenshot of interface error in edit mode.png]]
I'm getting the same on MW wiki.
Able to repro on 1.21wmf12 wikis. Increasing importance.
kipod: Next time I'd recommend filing a new bug report instead of reopening one that's been closed for years. CC'ing Greg as this seems to be another deployment regression.
(In reply to comment #12) > kipod: Next time I'd recommend filing a new bug report instead of reopening > one > that's been closed for years. > > CC'ing Greg as this seems to be another deployment regression. you might be right, but i'm willing to put modest amount of money (enough for a beer, at least) that this is the same problem and the same solution will solve it - you just need to find why the previous solution does not work any more. if i'm wrong here, take solace in the knowledge that it's not the first time i'm wrong, and hopefully not the last either. peace.
I believe this is now related to bug 46401.
(In reply to comment #9) > ... > > # open another (or same) article. > # note that some of the buttons from advanced toolbar leak into textarea > # repeat the last two steps until it actually happens. > > > Screenshot: [[File:Screenshot of interface error in edit mode.png]] (In reply to comment #14) > I believe this is now related to bug 46401. No, it's not. This bug has been in WikiEditor for years, if not since forever. It is a race condition triggered by a browser bug. I tried to reproduce it and I can, but not more or less than say 6 months ago.
And yes, this issue should've been re-opened earlier because r87979 either didn't fix it or it has been broken a few months back.
(In reply to comment #16) > And yes, this issue should've been re-opened earlier because r87979 either > didn't fix it or it has been broken a few months back. so if i hear you correctly, you agree that "reopen 27698" was more appropriate than opening a new bug? not that the answer is crucial - it's more about my curiosity/vanity... ;) peace.
(In reply to comment #17) > (In reply to comment #16) > > And yes, this issue should've been re-opened earlier because r87979 either > > didn't fix it or it has been broken a few months back. > > So if i hear you correctly, you agree that "reopen 27698" was more > appropriate than opening a new bug? > Yes, thanks for finding this one!
Hey Timo, do you have time to take a closer look at this one? I don't know if it's truly new, but it's a pretty serious UX bug with the toolbar that's trivial to repro.
*** Bug 46813 has been marked as a duplicate of this bug. ***
Adding Trevor.
Timo / Trevor: Could you please take a look at this?
Related URL: https://gerrit.wikimedia.org/r/58102 (Gerrit Change I2a842a86ef77a8934095c04408b7fabbcfbb2476)
Aforementioned fix by Trevor got merged into the codebase and will be available on MediaWiki servers as part of 1.22wmf2 between April 15 and 24. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for date details. Closing as FIXED.
Roan actually already deployed it; see https://wikitech.wikimedia.org/wiki/Server_admin_log#April_8 Fixed for me in prod as well.
This may have caused an unexpected side effect on test2wiki, but seems to be only on test2 and not other wikis. https://bugzilla.wikimedia.org/show_bug.cgi?id=47065
(In reply to comment #25 by Erik) > Roan actually already deployed it; see > https://wikitech.wikimedia.org/wiki/Server_admin_log#April_8 > > Fixed for me in prod as well. Seems to still happen for IE8, see bug 47506. Anybody else can reproduce?
