Page MenuHomePhabricator

Replace the primary scrollbar with a fake one to prepare for a persistent chat column
ClosedPublic

Authored by epriestley on Jan 23 2015, 3:26 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 3, 5:12 PM
Unknown Object (File)
Wed, Apr 3, 5:11 PM
Unknown Object (File)
Tue, Apr 2, 12:35 PM
Unknown Object (File)
Mar 25 2024, 11:37 AM
Unknown Object (File)
Mar 25 2024, 11:37 AM
Unknown Object (File)
Mar 25 2024, 11:37 AM
Unknown Object (File)
Feb 16 2024, 6:47 AM
Unknown Object (File)
Feb 11 2024, 5:15 PM

Details

Summary

Ref T7014. With a mouse plugged in, multi-panel UIs are pretty hideous on OSX. This is somewhat offputting for me in Conpherence, and really jumps out at me with the new column mocks in T7014.

Sites like Twitch and Facebook approach this by emulating the touchpad scrollbar to achieve a more aesthetic UI. Use a similar approach.

This:

  • Replaces the main scrollbar with a prettier fake one.
  • This prepares the standard page frame for a persistent chat column.
Test Plan
  • Seems to work properly on OSX, Chrome and Firefox. Haven't tested on IE; my Windows setup is pretty iffy at the moment.
  • Tried Conpherence.
  • Tried Workboards.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Replace the primary scrollbar with a fake one to prepare for a persistent chat column.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added reviewers: chad, btrahan.

Normal page:

Screen_Shot_2015-01-22_at_7.27.54_PM.png (656×1 px, 161 KB)

With scrollbar activated:

Screen_Shot_2015-01-22_at_7.27.58_PM.png (656×1 px, 161 KB)

webroot/rsrc/css/application/base/standard-page-view.css
147

I'll dump this into zindex.css

Tested many Windows browsers, all work well except >= IE8.

IE8 in Phabricator seems completely broken in general.

  • Dashboards don't load.
  • Diffs don't load.
  • This scrollbar doesn't load / locks page.
btrahan edited edge metadata.

I don't think it actually matters, but I am curious if there's times when its best to just appendChild rather than using the JX.DOM.appendContent or vice versa.

webroot/rsrc/externals/javelin/lib/Scrollbar.js
50

JX.DOM.appendContent maybe?

This revision is now accepted and ready to land.Jan 23 2015, 6:18 PM

except >= IE8.

Do you mean <= IE8? Or are IE9/IE10 toast?

If IE8 is totally broken it's probably OK to make it slightly more broken, but I don't want to break 9/10/11/whatever.

webroot/rsrc/externals/javelin/lib/Scrollbar.js
50

Yeah, I'll clean this up.

I mean less than or equal to

epriestley edited edge metadata.
  • Move zindex rule.
  • Use more JX.DOM.
This revision was automatically updated to reflect the committed changes.

please please please make it stop... https://code.google.com/p/chromium/issues/detail?id=337919 is when Chrome did the same thing.

Are you saying you want the Windows snap behavior, or just concerned that this is opening us up to a huge long tail of glitchy issues where our behavior is inevitably slightly different from the expected/OS behavior?

I fully agree on the latter, but our ability to do multi-panel UIs cleanly (like the mocks in T7014) is significantly hampered by not being able to use this technique. This technique is widely used on popular sites with multi-panel UIs (like Facebook, Twitch, and Slack), which makes me believe that acceptable results are achievable.

So far, all the glitches have been easily fixable. If we eventually get to a state where we have some remaining collection of unfixable glitches we could give you an option to always use OS scrollbars, but I'd like to make sure there are concrete behaviors with real impact that we can't successfully emulate first.

I'm also concerned about the huge long tail, but currently mostly worried about the lack of snap-back.

I don't see Slack, but for me it looks like both Facebook and Twitch use the native scrollbar (Chrome, Windows). Gmail and Google Docs use a non-native browser, but they have the right behavior for Windows (And probably make every Mac/Linux user cry).

To me, snap-back is essential for anywhere where a page may be more than ~2 screens high.

Can we skip this behavior if Conpherence isn't installed (though the feedback now is pretty helpful)

Snapback should be fixed in D11485.

We can definitely implicitly or explicitly disable these scrollbars, but I want everyone to complain about them first and see what the actual unfixable issues are.

This install should have snapback if you're on Windows, now. Does it work / feel OK?

That Chrome issue is crazy. I don't understand why they would add this behavior to OSes which don't have it.

Yeah, that feels good now.

The scroll element disappearing is something that requires getting used to;

In the Chrome event, users were complaining that the clickable area is too small, and the lack of "arrow keys" making precise navigation using touchpads hard. It's definitely smaller right now than I'm used to - this might be an issue here.
Specifically, the complaint was that grabbing it and throwing the mouse up to the reach the top wasn't working (It does work here now).

In chrome, the find feature marks all occurrences on the scrollbar - this is something I actually use a lot while reading code in diffusion, and I don't think it can be re-implemented; I don't know if/how other browsers do this.

The Chrome people just say "We do not place native behavior above what we think is useful behavior," which I can sort-of understand in the case of a browser (Which may be the "only" application many people use), but can't agree with :)

Cool. The "search results" thing is helpful, and we definitely can't emulate that.

I think we'll pull back from this at least slightly in the long run (that is, provide either implicit or explicit ways to disable it and use native scrollbars). Obviously, we gain no real benefit from putting it on pages without panels, except that right now we get to collect feedback about how broken/glitchy it is.

We want to try building an optional persistent chat UI (T7014) and the native scrollbar is super hideous if we make the page multi-panel:

Screen_Shot_2015-01-22_at_4.01.03_PM.png (879×1 px, 175 KB)

I don't know how universal my aversion to that scrollbar is, but I find them pretty offputting in Conpherence even now. Having a better sense of how practical it is to fake the scrollbar is helpful in approaching T7014. So far, it seems like we're in pretty good shape -- not perfect, but it seems like the fake scrollbars are generally good enough, and probably better in a multi-panel context for like 98% of users (i.e., slightly off in niche edge cases, but not hideous).

If we couldn't get the fake scrollbars to have reasonable behavior we might have to rethink our approach on T7014, but it looks like we're in "good enough" range. So I think we'll end up with one of these rules:

  • If the set of users who prefer native scrollbars overlaps very heavily with the set of users who hate the chat column, we can use an implicit rule like "use fake scrollbars only if the chat column is active".
  • If the two sets of users are more disjoint, we can add an explicit "always use native scrollbars, even though that will make the chat column UI pretty ugly" preference.

Another issue:

In the home page, mousewheel works when hovering over the application links themselves, but not in the gray area below them:

pasted_file (713×782 px, 125 KB)

This is only true in Chrome 41, 64 bit, Windows; Works everywhere in MSIE 11.

My initial reaction to the fancy scroll bars was to cry out in panic. It's possible there is nothing inherently wrong with the technique and that it's just that every other site I've seen that uses them is an unsightly, glitchy, inconsistent mess, but it's how those other sites have conditioned me to view it.

I think twitch is an interesting case since I use it often and the scrollbars there didn't drive me nuts. I think that's because my common twitch flow is:

So I rarely actually scroll on twitch unless (1) there is nothing on (2) maybe once a week I'll look below the video and see if the user changed their profile. With phabricator I scroll on many (most?) pages, looking for something, opening a bunch of tabs, even actually reading words arranged in paragraphs.

While I am definitely not a fan of these, I must commend you for the least bad implementation of custom scrollbars I have seen so far. :)

I'd love to see the ability to disable this that you hinted at in comment D11472#108675 above. In the meantime, I have used .jx-scrollbar-test { display: none; } in my user CSS, which tricks the initial test in this code and causes it not to use fancy scrollbars.

Shift+click on the scrollbar used to make the handle jump right there (Chrome/Linux but many other browsers/OSes too), that doesn't work anymore. Super annoying on very long pages.

Also, once you use the mouse to navigate the scrollbar (either by dragging or clicking), the page gets defocused and keyboard navigation does not work anymore.

Also also, if you focus in a comment box and press PgUp, you get two scrollbars.