@chad Chrome 41.0.2272.76 stable on Mac. I can reproduce it still.

@Krinkle, what OS/Browser is this specifically? I'm not able to find a repo case.

T7129 is very similar and discusses another type of non-file resource which users can drag and drop.

You can grab URLs from all over the place in lots of browsers (url bar, bookmark bar, tabs, etc).

Oh dang, that's gross.

From what I can tell, it seems like this is possible, but very complicated.

I'll merge it over in a half-baked way now, and will build something more formal once I have additional test environments set up and can confirm issues.

OK, thanks. If you let me know, I can test the fixes once they are available.

I am aware of everything you listed, so I've at least seen it in another task or it's be noted in the text of another task (either open or closed). I don't see a benefit to keeping tons of "scollbar is bad" tickets around, and more tasks as you can tell is part of that problem (there is no singular thing to point at). I will at some point in the very near future, collapse them into a single list of things to fix. These issues will not be around much longer, please be patient.

I'm seeing the same thing (what @kparal said) in Chrome 40 on Ubuntu.

@chad, I have went through all the issues in that Scrollbar column, and I have found only T7209 which seems to be a duplicate of problem 1) as described in my report. But it also might be a bit of something else related to trackpads. Problems 2), 3) and 4) doesn't seem to be covered in any of those issues.

I believe I have reported the same issue in T7363, when using mouse, Firefox 35, GNOME 3.14, Fedora 21. There is a space between the scroll bar and the edge of the window where it does not perform a bar grab, but page down move instead. Easily tested with maximized Firefox and moving the cursor to the very right (last pixel on the screen). Which is something I usually do, I just throw the cursor against the right edge and click.

Probably fixed

My tentative fix here was:

After poking at a few different solutions, I think the answer is going to end up being... use a table.

Nah, I've got it in a branch.

@epriestley, you want this to remain open for the D3.js upgrade?

There are two columns, one is Backlog, the other is Scollbar.

Can you point me to the duplicates please?

All Scrollbar issues are filed under PHUI for right now, you can add yourself to any/all tasks related (this is a duplicate of several of them).

Let us know if you see anything else!

Most / all of these should be cleared up, I only tested like 6-8 of them though.

Countdowns
Differential Revisions
Files
Flags
Legal Pad
OAuth

Which Query specifically? For example, Legalpad is broken, but Macro is not. I'm only actually concerned if one of the major ones is broken.

I agree with Ankur that the current stacking behavior that happens when you have more tabs than can fit in one row looks fine. The only visual tweak I would suggest is injecting a border between each row. I also prefer the horizontal layout even at small screen sizes rather than stacking the tabs as it currently does. Here is an example of multiple rows:

We're also pretty happy with the current behavior when the page is too small - the tabs just neatly display over two rows instead of one. It enables jumping to a specific tab very quickly in the interface.

I believe the main hangup was have Javascript collapse the tabs into a menu as the page shrunk. (Responsive layouts).

I have no problem scrolling with trackpad on Debian + Chrome Version 39.0.2171.65 (64-bit) OR Iceweasel (Firefox) 33.0a2 (2014-08-08).

I don't think we have that environment to test, and Mac/Chrome/Trackpad has different results (it doesn't make the bar appear at all).

Google Chrome, Ubuntu, trackpad.

Can you provide specific details to re-produce? Browser? OS? Mouse or Trackpad? etc...

• This likely affects all browsers and OSes.
  • This likely affects all scrolling actions: scrolling after clicking, scrolling with the mousewheel, multi-touch scrolling, etc.

Oh, that too huh ><

Cool. Thanks. Yeah, it is a minor thing for lazy, lazy users :)

It's not a security concern -- the only reason that we intentionally reject files is if they larger than the configured limits.

Not sure if it is the order in which Windows Explorer extracts files vrs. 7Zip, lack of browser support, or intentional design.

This now started to happen on diffusion's commit detail page, when I start to scroll before diffs from all files changed in the commit is loaded via AJAX.

Hrrrm, peculiar.

No, but oddly any DOM manipulation (turning any single rule on/off) made the scrollbar appear.

Does resizing the window before scrolling fix it? I can probably work around this pretty easily if so.

@epriestley, it looks like ajax'd content (dashboards) come in after page_height is figured out in JX.Scrollbar. Oddly this is only a trackpad only issue, I can't reproduce it when using a mouse.

I think I found a repro!

I dont see any claim by myself above stating scrolling isn't working. I've read the bug and watched the video. I've tried to reproduce the issue with no success. If you have other ideas on how we can reproduce the bug locally, it would be appreciated. I have Mavericks and Yosemite for Mac testing.

I'm not saying that scrolling isn't working. What I'm saying, and original video attached to task shows, that scrollbar isn't showing up during scrolling. And I guess you must set scrollbars to be hidden by default in OSX interface settings (I'm on Mavericks, no sure if it's issue on Yosemite).