Page MenuHomePhabricator

Decide the fate of JX.Scrollbar
Closed, ResolvedPublic

Description

Now that we're getting close to finishing Conpherence v2, we should figure out what the ultimate fate of JX.Scrollbar is.


For context, particularly for anyone coming into this ticket from the world at large, JX.Scrollbar is the fake scrollbar which replaces the real scrollbar. The reason we started using this fake scrollbar is to support adding a durable chat column to Phabricator:

Screen Shot 2015-05-10 at 8.44.50 AM.png (989×1 px, 289 KB)

You can activate this column by pressing "\" on your keyboard.

Specifically, without the fake scrollbar:

  • We get double scrollbars on the far right of the screen, which is a bad/confusing UX.
  • UIs with a lot of panels (the durable column, and the main Conpherence view -- especially before recent changes -- look ugly and cluttered).

The fake scrollbar was an attempt to fix these issues. Particularly, if we were designing this column for a desktop application, it would be a clear and obvious choice to put the page content scrollbar to the left of the chat column. The intent was to aim for that and see if it was achievable. Generally, we wanted to evaluate our options here and choose the best set of tradeoffs.


JX.Scrollbar works a lot better than I expected it would, and is essentially indistinguishable from normal scrollbars for me on Safari on OSX. However, this isn't the case for all users, and it has some behaviors which are unfixable or very difficult or complex to fix:

  • Scrollable panes and anchors are just really broken in a fundamental way in Chrome (T7740). We have a reduced repro case where the browser exhibits broken, surprising behavior that we don't think we can work around, and we haven't seen any meaningful progress on that from Chrome in more than a month.
  • Chrome has some sort of other major rendering issue (T7494) which is likely related and also probably not fixable.
  • Firefox on Windows scrolls panes very slowly (T7109). We can probably work around this, but it's very complex.
  • Various OS and browser-specific interactions, e.g. highlighting search results in the scrollbar gutter.
  • A collection of weird issues (T7128, T7209, T7466) which don't reproduce reliably.

Also notable: we've changed the left column in Conpherence so that it usually does not need to scroll. This has reduced the importance of JX.Scrollbar somewhat.


In general, note that there are really two separate things JX.Scrollbar is doing:

  • Putting page content in a scrollable pane. This causes almost all the major/serious problems.
  • Drawing a prettier scrollbar. This causes relatively few problems, mostly related to OS-specific interactions like "meta-shift-middle-click" not doing what users want.

Some possible ways forward, in rough order of commitment to JX.Scrollbar:

  1. Continue using JX.Scrollbar everywhere, and accept that it will be kind of glitchy for some users in some cases; keep working to mitigate those cases and hope that browser issues which we can't work around will be fixed eventually.
  2. Use JX.Scrollbar everywhere by default, but add an option to disable drawing the fancy scrollbars. We'd still frame the page content.
  3. Use JX.Scrollbar only when the durable column is active. This probably implies a jarring/slightly-glitchy transition, and would mean activating the column also activates all the scrollbar problems.
  4. Use JX.Scrollbar everywhere by default, but add an option to disable drawing the fancy scrollbars and framing the main page content.
  5. Stop framing page content. Use JX.Scrollbar only in Conpherence panels. Accept double scrollbar.
  6. Throw out JX.Scrollbar completely, and accept double scrollbars and more cluttered/ugly panel UIs.

If everyone was using Safari on OSX, I'd say (1) is a good option and maybe we do (2) to let alt-meta-middle-click work properly for build-you-own-linux-window manager users who probably compiled their own scrollbars from source anyway.

However, some of the Chrome stuff particularly is fairly debilitating. T7740 is an intensely confusing, broken UX. T7494 isn't as bad, but still a pretty bad experience.

To fix the Chrome stuff, we have to go at least as far as (3). I'd prefer not to do (3) or (4) because I think they make Phabricator much harder to test and develop in the long run: they give us two separate modes with a major fundamental layout difference. In the case of (4), switching between the modes would require a lot of work (adjusting a preference setting).

So that leaves us with (5) or (6). I'm inclined to try (5). In particular:

  • We have no option but to frame this content anyway.
  • We don't have any outstanding reports of glitchiness in Conpherence panels that aren't otherwise our fault. In panel contexts, scrollbars generally seem to work pretty well the overwhelming majority of users.
  • Being able to get rid of one of the two scrollbars goes pretty far toward remedying the visual confusion and business of double scrollbars.
  • If it's still too confusing, we could mitigate the visual issues through design of the column (for instance, separate it from the right edge by a few pixels and give it shadow to make it look like it is "popping down" from the menu or "popping up" from the bottom of the page). This isn't ideal, but seems like a smaller net price than framing page content, given the Chrome brokenness.

Event Timeline

epriestley renamed this task from Mitigate JX.Scrollbar problems to Decide the fate of JX.Scrollbar.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added projects: PHUI, Conpherence.
epriestley moved this task from Backlog to Scrollbar on the PHUI board.
epriestley added subscribers: epriestley, chad, btrahan.

D12789 implements (5). It accepts this visual compromise in OSX trackpad mode:

visual-margin.png (1×485 px, 92 KB)

And a similar "JX.Scrollbar + normal scrollbar" in non-trackpad mode.

These compromises feel OK to me. The "fake + normal" double scrollbar in mouse mode doesn't feel too confusing, and the visual affordance to provide a margin for the trackpad bar seems reasonable to me and doesn't jump out as ugly or clearly out of place.

To add my own personal notes on this:

I use Phabricator on Linux and Windows daily with Chrome; the only issue I've ever noticed is pages not jumping back to their position after refreshing the page (which I reported and I think got marked as Won't Fix?).

Anyway, the durable scrollbar does have some significant benefits on pages with lots of content. This is particularly noticeable on Harbormaster build pages when you've selected Unlimited lines to show in the build log. Before the durable scrollbar was used, scrolling in Harbormaster with unlimited lines was significantly laggy in Chrome on both operating systems and the experience wasn't very nice. With the durable scrollbar I get smooth 60FPS, even when scrolling (or more importantly, searching with Ctrl-F) through build logs, even when those build logs have 30000+ lines of output.

(5) Stop framing page content. Use JX.Scrollbar only in Conpherence panels. Accept double scrollbar.

When building your own scrollbars with a Haskell assembly generator running in a PDP-11 emulator, this would obsolete the workaround in T7323, correct?

I be the weird one and say that JX.Scrollbar is the best "fake scrollbar" implementation I've ever saw and if I wasn't using build-you-own-linux-window manager I wouldn't notice that scrollbars are different at all! For me - I'd go with (1) and say "it's not a bug it's a feature. Actually it's a bug in chrome, go and complain to google. You use Firefox? Well, that's a bug in windows, go complain there" ;-)

Yeah, option (5) (or option (6)) would obsolete T7323 in all cases.

(The new options in approaches (2) and (4) would more-or-less let you activate the workaround to varying degrees; (3) would obsolete it when the durable column was not enabled.)

Probably 5 / generally accepting that this is one of the Last Great Problems for the Internet to solve. (Once its done, world hunger is next I think.) Some thoughts -

  • T7740 is a big bummer and the real driver to me. How many users are on Chrome and how often do they hit this? I think the answer is enough people often enough that we're headed towards 5.
  • T7494 - my guess here is that this is something about how we autoscroll for the anchor and have some listener(s) not playing nicely and firing repeatedly. I am not sure this is just from the scrollbar basically.
  • T7109 - this is about making scrolling faster for Firefox + Windows. I think its balanced out by comments like T8151#113154 in that its not clear for me whats the net win for scrolling efficacy.
  • the miscellanous, hard to reproduce stuff also adds significant weight to 5 - hints at the long tail of ways this will be broken until people from the future can save us all and help us implement non native scrollbars

FWIW, I haven't run into any scrolling problems (including T7740) in either of these browsers

Chrome: Version 31.0.1650.63 Built on Ubuntu 13.04, running on LinuxMint 15 (31.0.1650.63-0ubuntu0.13.04.1~20131204.1)
Firefox: 26.0 aka Firefox for Linux Mint Version 1.0

Desktop enviroment is Mate 1.6.0.

Window manager is marco 1.6.1

I also have users on newer variations of the above with no complaints.

Approach (5) is now in HEAD and on this server. Let me know if anyone notices major scrolling problems that I missed.

The expectation is now:

  • With the durable column open, you'll get a double scrollbar. Hopefully, this isn't too visually confusing. If the double scrollbar is worse than the old stuff was, let me know.
  • These scrolling/framing issues should be resolved or obsolete -- pretty certain: T7740, T7109, T7323, hopefully: T7494, T7128, T7209, T7466; with durable column closed (Quickling off): T7978.

With the durable column open, you'll get a double scrollbar. Hopefully, this isn't too visually confusing. If the double scrollbar is worse than the old stuff was, let me know.

This looks & works better than I expected. At least in my case the second scrollbar only shows up if I interact with the chat column so the context is clear. I get that this is normal for OSX and that expectations vary, but the distracting disappearing behavior was a lot of what drove me nuts. With the current build I can interact with the chat column without visually loosing my place in the page; in other words the double scrollbar actually ends up being an unexpected virtue from my point of view.

On mobile, the columns are compressed on the left hand side of the window, and the right hand column of the window is blank, just the grey background (where the durable column would be). Seems to affect all pages so far (homepage, maniphest)

Tested on: iOS 8.3, safari.

Durable column layout issue (1×2 px, 403 KB)

What physical device are you on? I can't immediately reproduce that on any iPhone/iPad...

iPad Air2, in landscape (also happens in portrait, just tested)

Attached diff probably resolves things? I was seeing something similar on my mac using chrome with a trackpad.

The layouts on secure.phabricator.com appears to be fixed for me

epriestley claimed this task.

I'm going to tentatively call this resolved since things have been quiet for a few days now, but I'll keep an ear open for more feedback.