Here is our multimeter data:

I've most often noticed this when "associating project" on a Maniphest task. I'd sometimes have to wait several seconds for the typeahead to appear.

I would love it to remember my last 50 people. (Projects too!)

Though sometimes I'm typing as fast as I can adding multiple people, in which case I'd still have to wait for the first user before typing the second user?

Oh, so you're typing as fast as you can and immediately tabbing out of the field (in less than a second)?

Yep!

Alternatively, we could require usernames to contain a minimum of 16 characters with at least one uppercase letter, one symbol, and three or more of the same letter in a row.

Oh, so you're typing as fast as you can and immediately tabbing out of the field (in less than a second)?

On this site, in the user field, I can type my whole username "liza" and hit tab/enter before the typeahead comes up. I run into this a lot in the project field in our installation, too. If the next name is similar to mine, e.g. "lisa" (or on this site "lizarc"), they'll probably appear within 1-2 characters, but if it's totally different, e.g. "angie", then I can still type at least 4-5 characters before the typeahead appears.

Oh, you may have to click "(All)" under Request to expand that column to make it look like the screenshot.

These execute with a median speed of about 150ms on this install, for the ~1,200 requests made in the last 24 hours (this is across all typeahead source types).

Does is seem faster here? Which typeaheads specifically seem slow?

This is presumably obsoleted by the new scrollbar behavior.

I like at least trying the last item as a dropdown. There are a couple of other similar "make UI elements work better on mobile by default" things too (T5752) that I sort of want to clean up, but holding these until after the redesign probably makes sense.

Presumably obsoleted by T8151, reopen if this is still an issue at HEAD.

Presumably obsoleted by T8151, reopen if this is still an issue at HEAD. This is probably a Chrome bug if it's not fixed at HEAD.

Presumably obsoleted by T8151, reopen if this is still an issue at HEAD.

Presumably obsoleted by T8151, reopen if this is still an issue at HEAD.

Presumably obsoleted in HEAD.

Obsoleted in HEAD.

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.

Yeah it makes sense in most places, but in Phriction it's the only way to access the parent document.

FWIW, crumbs on mobile have always (deliberately) done this.

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

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

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

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

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)

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.

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

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

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 -

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

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" ;-)

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

To add my own personal notes on this:

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

Actually I had been hitting it a lot in the past week, need to look into it again I think. This is Mac/Chrome/Desktop

@chad do you need any more help reproducing this/is this fixed? I just noticed this behavior after our office upgraded to a more recent Phabricator build and it is totes annoying, I can also reproduce it with 100% reliability.

Oh, I know why. We fixed Differential to 1-up view and that was the only example.

Yea... I don't see it anywhere

You can make this one King if you find it first!

But in the other task is there a fancy video? :D

(this is a regression in Chrome)

There is already a task for this somewhere, but I'm having issues finding it.

T8077 is similar issue but for images drug in, though we shouldn't be trying to convert images if we don't know if it's a file (and filling logs)

Presuming this is resolved, but let me know if that's not the case.

¯\(°_o)/¯

(Including discussion of the possibility of summarizing, hiding, etc., older inlines.)

I'm going to merge this into T7447, which has some ongoing discussion about this feature.

So maybe it should be shown as a header with a possibility to show full comment? We sometimes encountered situation that there are too many comments in same place, but only few of them are relevant

One reason to show old inlines even when they are marked "Done" is that the reviewer who added the inline may want to verify that it is actually done when they look at the updated diff.

Firefox is Fire-awesome.

I guess I value the native scrollbars way more than you do.

RTL doesn't flip scrollbars for me on that fiddle:

Once you have chat and nav, you're taking up 40% of the page before the user's content even starts. I think it'd feel a bit awkward.

What about floating the chat column on the left side of the page? Or moving the native scrollbars to to the left side of the main frame (http://jsfiddle.net/avrahamcool/uPwfn/1/)?