I am not familiar with the term "hamburger", so excuse my lack of clarity on this issue.

I can ask that you check if the problem occurs here as well: https://phabricator.wikimedia.org/project/board/5/

If so, this is outside of the sprint context.

@Christopher: The bug does not occur on https://phabricator.wikimedia.org/project/board/5/

I'm not sure what was meant by hamburger either but they are referring to the little dropdown menu in the top-right corner when the browser is narrow enough to hide the sidebar menu. In one case the sidebar menu's items collapse into the top dropdown menu, in the broken case the sidebar just disappears but doesn't add it's menu items to the dropdown.

It seems like phabricator is loading the dropdown menu items based on the "application" context, perhaps the /tag url is mistakenly treated as maniphest application context? Because in the case of /tag it loads my maniphest saved queries into the menu instead of the project board menu.

@Christopher: Is /tag using a different controller from /project/board/X?

This seems like it is likely to be the culprit:

https://phabricator.wikimedia.org/diffusion/PHSP/browse/master/src/controller/SprintController.php;f4940152eafb1a7d72b486bfb03d9acb8654b7d4$56

id(new ManiphestTaskSearchEngine())
    ->setViewer($user)
    ->addNavigationItems($nav->getMenu());

Why does sprint add the maniphest naivgation items?

here's your hamburger:
http://www.theatlantic.com/product/archive/2014/08/the-hamburger-menu-debate/379145/

but I don't know much about the history and haven't read that yet.

/project/board/5/ does seem ok

@mmodell correct, the buildSideNavView method is the "culprit". This is called from buildApplicationMenu which is part of the main stack buildApplicationPage called by PhabricatorController. The Project application abstract controller class "hamburger menu" requires a $project object from which it gets the project ID, if it exists. If it does not then it adds a "Create Project" link in the menu. The Sprint application abstract controller does not require a $project object, because there are views, like the Sprint List, where it is not needed (nor accessible).

The fix is to get the ID from the request, if it exists. Otherwise, if it is a "slug" in the request, call a lookup function which does a project query and returns the ID from the slug name. Patch is forthcoming.

Change 214433 had a related patch set uploaded (by Christopher Johnson (WMDE)):
fixes "hamburger menu"

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

Thanks @Christopher! looks good, I guess this gets deployed on the 10th.

Was not fixed by the deployment on 2015-06-03 23:59UTC as I can still reproduce.
@mmodell: Is there a task to mark this as blocked by the next pull?

Change 214433 merged by Christopher Johnson (WMDE):
fixes "hamburger menu"

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