Last modified: 2014-11-04 09:19:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T56919, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54919 - [collapsibleTabs] Tabs (Read / View Source / Search) wrap to next line and cover content if screen width < ~700px
[collapsibleTabs] Tabs (Read / View Source / Search) wrap to next line and co...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.22.0
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 53442 64228 68670 72876 (view as bug list)
Depends on:
Blocks: 44386
  Show dependency treegraph
 
Reported: 2013-10-03 13:46 UTC by Gavin Munro
Modified: 2014-11-04 09:19 UTC (History)
11 users (show)

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


Attachments
English Screenshot (201.59 KB, image/png)
2013-10-03 13:46 UTC, Gavin Munro
Details
yasc (yet another screenshot) (27.63 KB, image/png)
2013-10-10 23:51 UTC, kipod
Details
Happening at 1024px-wide screen on Ukrainian Wikipedia (43.44 KB, image/png)
2014-02-09 23:27 UTC, YurB
Details

Description Gavin Munro 2013-10-03 13:46:38 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.
Comment 1 Andre Klapper 2013-10-03 15:53:51 UTC
*** Bug 53442 has been marked as a duplicate of this bug. ***
Comment 2 Andre Klapper 2013-10-03 15:58:28 UTC
Confirming (and sorry for incorrectly marking your previous report).
Comment 3 Bartosz Dziewoński 2013-10-03 18:08:02 UTC
(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).
Comment 4 Gavin Munro 2013-10-03 23:14:41 UTC
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?
Comment 5 Bartosz Dziewoński 2013-10-03 23:20:31 UTC
(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.
Comment 6 Gavin Munro 2013-10-04 00:08:34 UTC
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.
Comment 7 Andre Klapper 2013-10-06 20:58:35 UTC
(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).
Comment 8 Gavin Munro 2013-10-08 07:15:45 UTC
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.
Comment 9 Bartosz Dziewoński 2013-10-08 19:19:27 UTC
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.)
Comment 10 kipod 2013-10-10 23:51:04 UTC
Created attachment 13473 [details]
yasc (yet another screenshot)
Comment 11 kipod 2013-10-11 00:04:46 UTC
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.
Comment 12 Gavin Munro 2013-10-11 00:07:01 UTC
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.
Comment 13 YurB 2014-02-09 23:27:45 UTC
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.
Comment 14 Bartosz Dziewoński 2014-04-22 10:35:32 UTC
*** Bug 64228 has been marked as a duplicate of this bug. ***
Comment 15 James Forrester 2014-06-01 22:30:15 UTC
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.
Comment 16 Bartosz Dziewoński 2014-07-27 12:54:02 UTC
*** Bug 68670 has been marked as a duplicate of this bug. ***
Comment 17 Bartosz Dziewoński 2014-11-03 22:21:47 UTC
*** Bug 72876 has been marked as a duplicate of this bug. ***
Comment 18 Michael M. 2014-11-04 09:19:39 UTC
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.

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


Navigation
Links