More button bug?

.... I would like to know how under any circumstances and in any way a conflict between a third-party modification and a third-party skin is an IPB bug?
You read through that, I'm certain you will realize the futility of this 'bug report'.

.... I would like to know how under any circumstances and in any way a conflict between a third-party modification and a third-party skin is an IPB bug?
You read through that, I'm certain you will realize the futility of this 'bug report'.

Actually, it's nothing to do with add-ons at all - perhaps you should read Ryan's thread here (including the responses from Ryan H and Wolfie) rather than getting antagonistic towards another member reporting something he sees as a bug.

Now, you're only going to notice this bug if you have a very specific number of apps installed (i.e. enough that you will have precisely enough tabs to fit into the space, but not enough so that a More button cannot fit). This seems to jive with my own experiences, even using the IP.Content navigation. It is pretty minor but a tad annoying, and I'd rather not have to introduce kludgy hacks again (previously, my own application would prevent the more button appearing by overriding ips.global.activateMainMenu and replacing it with an empty function. At least I think that's the function off the top of my head).

Agreed. I managed to do the same on this site with resizing my browser window.

Screenshot

Hmm? Take a look at Lewis snapshot Mat and me was right already that the add-on was not causing it. Of course it is the way I think and see.

No edit option? no problem I will add this sentence to another reply post below.

Since Kyanar stated that you should read my thread and its at http://community.inv...e-menu-problem/

Update: Maybe to disable more button is not a good idea because what if other people uses a different resolution but i still think it is a bug if there was just one button in more button.

As I mentioned in that thread, I suspect the 'more' button itself may be factored into the width calculation that determines whether it's used or not. That would account for the ~70px gap that's required to get all links to display. The same seems to be true on this site. It's been a while since I dug through the JS for that, but it seems to me there's a simple CSS class that could be added to prevent that.

Updating Status to: Confirmed - Skin Issue
Updating Version to: 3.3.4

-

As I mentioned in that thread, I suspect the 'more' button itself may be factored into the width calculation that determines whether it's used or not. That would account for the ~70px gap that's required to get all links to display. The same seems to be true on this site. It's been a while since I dug through the JS for that, but it seems to me there's a simple CSS class that could be added to prevent that.

I actually sat and played with this a bit in ipb.js today, the issue is twofold, while the more button width should *not* be used in the initial width calculation(the ccs class would not help, this is hardcoded in and skipped in the loop to measure/insert if needed the li's into the menu), when the more menu is validly triggered, it DOES need to count the more tab in calculations lest the more appear on the second line.

I actually sat and played with this a bit in ipb.js today, the issue is twofold, while the more button width should *not* be used in the initial width calculation(the ccs class would not help, this is hardcoded in and skipped in the loop to measure/insert if needed the li's into the menu), when the more menu is validly triggered, it DOES need to count the more tab in calculations lest the more appear on the second line.

That said... i got *something* to work, dunno how valid.

// Set up the main menu
activateMainMenu: function()
{
if( $("nav_other_apps") && $("community_app_menu") ){
/* Image is 0 width inside hidden div, so we have to compensate manually...hardcoded for our useropts image 17px + 3px margin */
/* Note that we are grabbing width of more menu tab, instead of 'margin-box-width' which accounts for margin. Cannot grab this
value while the tab is hidden and we don't want to loop a second time unnecessarily to readjust after showing the menu
... wait... what? show then hide it measured done why hard-code this image width and margin?*/
$("nav_other_apps").show();
var start = totalW = $("nav_other_apps").measure('margin-box-width');
$("nav_other_apps").hide();
var menuWidth = $("community_app_menu").getWidth();
/* Add up the widths of any menu items we won't be moving to the more menu */
$("community_app_menu").select("li.skip_moremenu").each( function(elem){
totalW += $(elem).measure('margin-box-width');
});
$("community_app_menu").select("li:not(#nav_other_apps,.submenu_li)").each( function(elem){
/* These tabs should not be moved to the more menu */
if( $(elem).hasClassName('skip_moremenu') )
{
	 return;
}
totalW += $(elem).measure('margin-box-width');
if( totalW >= menuWidth )
{
	 if( !$("more_apps_menucontent") ){
	 $$("body")[0].insert("<div id='more_apps_menucontent' class='submenu_container clearfix boxShadow'><div class='left'><ul class='submenu_links' id='more_apps_menucontentul'></ul></div></div>");
	 }
	 $(elem).addClassName('submenu_li').removeClassName('left');
	
	 $("more_apps_menucontentul").insert( elem ); // Move item to menu
}
});

// Do we have an app menu?
if( $("more_apps_menucontent" ) )
{
//did we booboo and make an app menu when we shouldnt have?
if($("more_apps_menucontent" ).down('li').next())
{
$("nav_other_apps").show();
new ipb.Menu( $('more_apps'), $('more_apps_menucontent') );
}
else
{
$("nav_other_apps").replace($("more_apps_menucontent" ).down('li').removeClassName('submenu_li').addClassName('left'));
}
}

Debug.write( menuWidth );
}
},

basically, if only 1 item is present, replace the more tab with it.

^ not going to work, there still remains that issue of long 'last' causing a second line, have fun Ricki.

Updating Status to: Not a Bug

I know it looks like a bug in Lewis's screenshot, but the problem is the math actually adds up.
 
Each tab has a padding to the left and right of the text so that the text on a tab is centered appropriately.  Then there's a margin between the max width of the menu and the "View New Content" tab.  If, in Lewis's screenshot, the "Tracker" text was brought up to the More tab, it would be wider than the available widths added up allow, hence why the tab was added to the More menu.
 
We will revisit how this works in 4.0 when we redesign the front end, but for now it's working as designed and you happen to have hit a niche case where you could make it look ok, even if the math doesn't allow what you want.