• 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).

gavinmunro wrote:

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.

gavinmunro wrote:

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).

gavinmunro wrote:

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
yasc (yet another screenshot)

Attached:

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.

gavinmunro wrote:

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
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.

Attached:

• 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.

I tried to make the fallowing change the elements so that when the size(i.e the width) of the window is decreased then the read,edit links would become collapsible so that they move under the more tag and when the previous size is restored they again come back to the normal ones

Does the thing go right with the issue here which prevent the overlapping of the those links?

I don't understand the last question, but the screenshot looks pretty good to me, congratulations! :)
Please update your code changes as a patch in Gerrit when you think they are cleaned up and ready for a review / some feedback.

@Aklapper the question I asked above is when the width of the page is too less than the present (or above) screen shot ,I think the js code is written in the way so that the more option slides down for the screens of too less width if it is the case then it overlaps with the header(most probably) then should I remove that part so that it doesn,t slide down and make "Discussion" collapsible in the more option when the width is too less?

I do not know what's the best approach, sorry.
Maybe some designers or developers could provide feedback...

@Aklapper I have edited the code in the fallowing way so that all the items such as read etc moves under more dropdown and works in <700 px screen even after logged in and I think through this change there would be no overlapping of the code this is the screenshot of the code I have edited

@Rammanojpotla: Impressive! You are very welcome to use developer access to submit your proposed code changes as a Git branch directly into Gerrit which allows reviewing them and providing feedback. If you don't want to set up Git/Gerrit, you can also use the Gerrit Patch Uploader. Thanks again!

Change 366845 had a related patch set uploaded (by Rammanojpotla; owner: Rammanoj):
[mediawiki/skins/Vector@master] Canged an if condition so that all collapsible class is applied to all the variables and also edited a css code to prevent the repeat of the image in the dropdown

https://gerrit.wikimedia.org/r/366845

@Aklapper can you review and leave a comment on the gerrit page is there any mistake in the code I have edited?

@Aklapper i have modified the commit message and pushed it it returned me an error giving cannot merge and asked me to rebase when I rebased the code there was a large number of lines get newly added and all the patch sets contain the code the changes which I have not made can you review it once and may I know what had happened? I try abandoning it and push a new change

Change 366845 abandoned by Rammanojpotla:
Tabs (Read / View Source / Search) collapsed under more in resolution < 700px

https://gerrit.wikimedia.org/r/366845

Change 368799 had a related patch set uploaded (by Rammanojpotla; owner: Rammanoj):
[mediawiki/skins/Vector@master] Tabs (Read / View Source / Search) collapsed under more in resolution < 700px

https://gerrit.wikimedia.org/r/368799

Change 368799 abandoned by Rammanojpotla:
Tabs (Read / View Source / Search) collapsed under more in resolution < 700px

https://gerrit.wikimedia.org/r/368799

Change 368803 had a related patch set uploaded (by Rammanojpotla; owner: Rammanoj):
[mediawiki/skins/Vector@master] Tabs (Read / View Source / Search) collapsed under more in resolution < 700px

https://gerrit.wikimedia.org/r/368803

(For clarification: No need to ping me here, I am not a developer / reviewer :)

Change 368803 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Tabs (Read / View Source / Search) collapsed under more in resolution < 700px

https://gerrit.wikimedia.org/r/368803

Ok I've merged the patch, this should go live next week following the normal mediawiki deployment train process.

@Rammanojpotla: thank you for your contribution!

Change 379825 had a related patch set uploaded (by 20after4; owner: 20after4):
[mediawiki/skins/Vector@master] Consolodate duplicate css rules.

https://gerrit.wikimedia.org/r/379825

Change 379825 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Consolidate duplicate CSS properties

https://gerrit.wikimedia.org/r/379825