Last modified: 2014-11-04 09:19:39 UTC
Created attachment 13429 [details] English Screenshot I previously reported this bug as No. 53442 and this was determined to be a duplicate of 47506. I have reviewed 47506 but this is not the same bug. 47506 apparently is intermittent and sometimes moves some icons on the line down. This bug started in the English Wikipedia where the tab line wraps and overwrites the following line when the screen is reduced to half width. It seemed to correspond with the introduction of the full-screen editor. This originally occurred only in the English version and started only about two months ago (about July 2013). Prior to that it was fine. At first the French wikipedia was unaffected but it now also occurs there and I have also seen it in the German. It is easy to reproduce - go to the Wikipedia Home page (or any page), reduce the screen width to half width and observe the tab line wrap-around obscuring the title. Note that this does not only occur when editing but always happens whether editing or not. I use Chrome but it also occurs in Internet Explorer 8.
*** Bug 53442 has been marked as a duplicate of this bug. ***
Confirming (and sorry for incorrectly marking your previous report).
(In reply to comment #0) > This bug started … about two > months ago (about July 2013). Prior to that it was fine "Fine"? The tabs overlapped, rendering certain links inaccessible. What you're asking for is the inverse of what was fixed per bug 20234. I believe the current behavior is less wrong. Alternatively, someone could come up with a magical method that makes oversized navigation tabs fit. I didn't figure out any myself, though, and nobody on bug 20234 did either (and it was reported in 2009).
If I recall, previously there was a down arrow where you could access the tabs that were not visible which I thought was a good solution and similar to the solutions adopted in the major browsers like Chrome and IE8. If a wrap around solution is preferred then could the text be moved down a line so that the wrap-around does not cover the heading?
(In reply to comment #4) > If I recall, previously there was a down arrow where you could > access the tabs that were not visible which I thought was a good > solution and similar to the solutions adopted in the major browsers > like Chrome and IE8. This was only done – and still is done – for the "History" link. Don't ask me why. > If a wrap around solution is preferred then could the text be moved > down a line so that the wrap-around does not cover the heading? It would require a large rewrite or an ugly hack. But it's technically possible, yes.
If there are technical problems then one alternative could be to have an option for the old and new method - similar to the option for the old and new editor. Another option - I noticed a gap between the two lines of wrapped text: if this gap could be eliminated and perhaps the tab line reduced in height when half width then perhaps the headings would not be covered. I dont know if this is easier than moving the text down a line or not. I do not have technical knowledge as to the feasibility of different options unfortunately. By way of explanation, I do translations and my method is to put two windows side-by-side to read in French and write in English. As I have several Chrome tabs open and switch between them, seeing the headings helps me to identify where I am plus I also frequently have to copy the headings. This problem definitely slows down the work.
(In reply to comment #6) > one alternative could be to have an option for the old and new method No options please for such stuff to clutter the preferences interface. I mean, which user would expect something like this to be an option? It's a bug and the right way to fix it seems to be clear (though complicated).
As of today this bug seems to be fixed. Great! But it still occurs in the French wikipedia. Do I need to report it there? My French is not really up to reporting bugs.
I don't think anybody fixed it, so it should not be fixed. Can you make a screenshot of what you're seeing and attach it here? (Use the "Add an attachment" link above bug comments.)
Created attachment 13473 [details] yasc (yet another screenshot)
oooops.... i meant to continue comment 10 some more, so here goes: REPRODUCTION INSTRUCTIONS: 0: use google chrome (tested with v30), firefox (tested with v24), or IE (tested with ie10) 1: open enwiki: https://en.wikipedia.org 2: grab the right edge of the browser's window with the mouse, and start moving it left, slowly. at some point, the #right-navigation div will drop down. 3: shortly thereafter, #p-cactions will swallow the "history" tab, and #right-navigation will jump back up. do not despair, and continue dragging the edge leftward, until the div drops again. 4: now it stays dropped. peace.
Dont know what happened to my comment yesterday - it seems to have disappeared. Anyway, yes it seems I must have used a screen very slightly wider which made it appear the bug had gone. The French wikipedia is different in that tabs are wider due to longer text. So the bug appears there at about two thirds of the screen width. So the width of the tabs makes a difference and now I am thinking that I may first have noticed this problem when the "Talk" tab was changed to the "Discussion" tag (Why?) making the width slightly wider.
Created attachment 14539 [details] Happening at 1024px-wide screen on Ukrainian Wikipedia Since the addition of the "Edit code" button at Ukrainian Wikipedia this bug started happen even on a 1024px-wide screen that is very common in netbooks.
*** Bug 64228 has been marked as a duplicate of this bug. ***
Current worst-case scenario I believe is: * German-language UI (longest i18n) * logged-in user (get the labelled additional actions menu per bug 44591) * on a wiki with VE active (two edit tabs) * looking at a file page with a remote file but no local description (long wordy descriptions for the complicated logic, and another tab) Observe (whilst logged-in): http://en.wikipedia.beta.wmflabs.org/wiki/File:Example.jpg?uselang=de … at 800px you get only the read tab (no edit tab at all!), and you need ~1400px (!!) to get the whole set of five action tabs.
*** Bug 68670 has been marked as a duplicate of this bug. ***
*** Bug 72876 has been marked as a duplicate of this bug. ***
From bug 72876: On "normal" pages the "Read" tab will not be collapsed, but when the FlaggedRevs extension is used and there are pending changes for the current page, it will be collapsed. This behavior actually doesn't make much sense. When it is okay to collapse the "read" tab on pages with pending changes (and IMHO it is okay), it is okay to collapse it on all pages. (In reply to James Forrester from comment #15) > http://en.wikipedia.beta.wmflabs.org/wiki/File:Example.jpg?uselang=de > > … at 800px you get only the read tab (no edit tab at all!), and you need > ~1400px (!!) to get the whole set of five action tabs. You don't get the edit tab because the file is on Commons. On file pages for local files (and all other pages), the "edit" tab will never be collapsed.
