This is coming back in some form, it's just temporarily disabled while we work through some redesign stuff. I have some big plans for it that I want to try playing around with; if they pan out then I think the new version will be way better and fix a lot of the problems the old version had. I'll add more details here once I have some more concrete designs.

If people are REALLY UPSET we can probably restore the old thing and just CSS it down 44px, but I want to try getting rid of it for my fancy new version anyway so I'd rather get all the rage out now. :)

Rough cut of the new local navigation:

{F17517}

Pretty!

◀ Merged tasks: T959.

Can you change the colors of the files in the treeview like:

• Deleted -> Red
• Added -> green
• Modified -> blue

Hey, this has bad behavior when you scroll horizontally. The code/diff display mingles oddly with the table of contents. This is on chrome (also on android [which has far worse issues than this])

I can't reproduce this on Chrome on the Desktop (see attached) and I don't have an Android device -- it should have been fixed by rPd5b16c93ca2ead806d9afaa482727cf476e37e59, is it possible you aren't up to date? Does it repro on secure.phabricator.com?

oops! updating fixed it...

This is pretty, but can we pretty-please get a key command to hide/reshow this entirely? The lost space on the left-hand side of laptop screens is a pretty big bummer.

Can we just default it to hidden if your screen is less than X pixels wide?

X = 768

Agree that auto-hide would be useful, but the ability to show / hide in any case (via a key command like z for comments) would be much more powerful, as the left-hand side is not always needed.

Is there still an eventual plan to add it back? Currently I don't see either the left-side local navigation, nor a sticky header.

In the meantime, I'm using a Chrome extension that a coworker (Brenton Bade) made to have sticky headers back which seems to work pretty well so far.

Local navigation is now a default-disabled preference. You can turn it on in your settings (hiding it is also sticky now; you can toggle it with "f" if it's enabled but hidden I think).

The header might come back some day but probably not soon.

Oh, interesting. Didn't know about that one.

Is it a bug that the local navigation doesn't highlight which file you're currently looking at? Or was that canceled too?

That's a bug.

I was able to hack together an extension that gives sticky headers pretty easily. I'm no JS developer, so the code might be crappy, but so far it works without issue.

https://secure.phabricator.com/P856

@epriestley, would this be easy to put back in? If you still don't think so, i'll probably share this with more people internally.

It won't be coming back any time in the near future. It created a host of difficult-to-solve problem reports from users like "command-F in firefox is underneath the header after search wraps" and "I think it's really slow in Chrome? I don't know, but it feels REALLY slow" that I don't want to deal with.

Basically, both the header and file view are features that 5% of users really like, 10% of users loath with a limitless hatred and believe to be the worst things in existence, and 85% of users don't care about.

e.g., even in this task we had this:

The filename was a bit silly before too because when you clicked on an anchor it would scroll to that position, but the first line would be hidden behind this bar, which was kind of annoying. One possible solution would be to make the bar only take as much horizontal space as necessary to display the filename, and no more. Then in most cases you wouldn't have that overlap.

I don't think any user ever said "this feature is good just the way it is and I am happy with it as-is".

I would expect P856 to have significant performance implications for large changes given how much it interacts with the DOM in response to onscroll (and how is $ getting defined? Are you including jQuery somehow or something?), but maybe it's fine in practice. I'd suggest maybe loading up a diff with a large number of changes and scrolling through it to make sure it doesn't cause the browser to start locking up near the bottom of the page before you promote it more widely.

If you want to restore the original version, add configuration for it, default it off, and support all the user complaints I'm tentatively willing to accept it in the upstream -- the major technical changes which interacted negatively with it (fixed-position nav) have been reverted.

The header revert happend in D3355.

The wrapping search issue is D1673#7.

The phantom report of it being (unreproducibly) slow was T959.

My plugin consists of 3 files: jquery, the script, and then a tiny manifest.js . Chrome very handily sandboxes the entire plugin, so you can program as if your script and its dependencies are the only things running. So far I haven't seen any performance issues, but I haven't looked at *huge* diffs either. So far it's been "Good enough for me", but I'll be testing it more.

Via FB / pitchforking.

Rough cut of the new local navigation:

@epriestley, would this be commited at some point. I don't see that small navigation right now no matter how small my browser window is.

I have the "File Tree" enabled in commit view and I like it. However it would be great if currently viewed file can be highlighted in it. I can either click on a file in file tree to make it current or scroll to it manually and file tree still needs to be up to date.

◀ Merged tasks: T5802.

Could we solve the problem of knowing what file a patch is for without scrolling just by adding a tooltip to, say, the line numbers? (Even the browser tooltip would work.) It doesn't have to be immediately visible, I just want to find out the file without scrolling!

I just want to note that we fixed this in less than 5 years. Learn how in my upcoming book "Unbelievably Agile Ultra-High-Velocity Software Development Which Goes So Fast it Almost Must Account For Relativistic Effects".