I did some further digging and made a little progress

n/m, I see this was fixed today with https://secure.phabricator.com/rP1f2306999bb599bcedc0c4bfff2f2b3aade58630

I think this should be fixed by D17146, which landed a few hours ago. Presumably you're running some ancient stone-age version of Phabricator that's 6 or more hours old?

I think I got all of these, but yell if you catch any more.

This should do it:

Yep, here is the default value on all the installs of PHP I've done from source:

Am glad to get ahead of it. What's the exact incantation we need to put into our php.ini?

(After T12071 we will almost certainly require "E", so you could get ahead of that now.)

Actually, it looks like PHP defaults to "EGPCS" but ships with config files that use "GPCS" (??? why would you do this ???), so this is probably not something that got changed or configured intentionally or accidentally.

Perfect, thanks! That's what I expected, so D17148 should resolve this. Alternatively, setting that value to "EGPCS" (without upgrading, just restarting the daemons) should also resolve this.

I believe this is now fixed at HEAD of master. You should be able to pick up the change with arc upgrade now (if you run master) or in about 36 hours (if you run stable).

While I'm chasing this down, can you show me the output of this command?

This is an unintended side effect of D17100 but resolution isn't straightforward.

This is D17122 interacting with some extremely high-quality code in arc.

This is far afield from an actionable bug report.

Yeah, There is no postfix, but my distro (SUSE Linux Enterprise) sendmail is a postfix variant. I have to match your sendmail config to my postfix. The last part was done with the help of canonical which is wrong way to do it probably. If it is too much work to debug this just drop it. It seems to be a very special case of configuration, server variant.

Using postfix instead of sendmail

Sorry for the typos :D, Step by Step Guide:
Follow this: https://secure.phabricator.com/book/phabricator/article/configuring_inbound_email/#local-mta-installing-mai (Local MTA Section)

We could possibly remove it entirely since I think it isn't useful for 99% of users, but D17144 just fixes the command.

Funny, never knew we put that text in that drop down.

Sorry, Step By Step Guide:

Please read Contributing Bug Reports carefully, specifically we require a complete, easy to follow and under.stand, set of steps to reproduce the problem.

Please read Contributing Bug Reports carefully, specifically we require a complete, easy to follow and under.stand, set of steps to reproduce the problem. I also don't understand what you're saying the bug in Phabricator is.

So, just some insight, I use postfix as mail server and for catch all mail (@domain) I used the canonical approach. This results the error above. Using virtual as described here will solve this problem.

On my laptop it triggers either to the right of the preview icon or to the bottom, on my desktop, it does top, and gets jittery.

I think this really is the same as T10687, but the jittery bad degenerate behavior is only when a scrollbar gets added, so probably laptop + mouse works to repro but not laptop + touchpad?

Thanks for the excellent bug report with high-quality reproduction steps. Your clear, thorough reproduction steps made fixing this issue extremely easy!

Cry in vain this step is optional.

Actually, this is a haunt mode bug, I'll update the description with a full set of reproducible steps.

Chrome upstream has patched this, now:

This is working as intended.

I just tried it on GitHub an see that you're right. I guess this finally shifts this task into the feature request area, for which I would like to present the root cause: What I actually tried to achieve, when searching for for "PhabricatorProfilePanel", was to figure out in which commit this symbol got removed from Phabricator, so as to know how to change my extension's code (T10308#205605) to make it work with current Phabricator.

@jeremy.norris - You should be able to push if you use a mercurial client 3.4 or below. What I did is download the hg-3.4 sources and do make local, then moved the renamed binary into my path (/usr/local/bin/ I think), and I use hg-3.4 push -r master when pushing.

So reading through all of this, am I understanding correctly that Phabricator and Mercurial > 3.4 aren't compatible with each other? I've spent the past couple days attempting to push an existing repository with a few thousand changesets into a Phabricator hosted instance to no avail (using mercurial 4.0.1 for both the client and server).

I was able to reproduce this at HEAD and D17134 should fix it, but please make sure future issues you report are against upstream code -- not forked local code -- and that your install is up to date. Many issues are already fixed by the time they are reported, and we are powerless to troubleshoot issues with local code even if we wanted to.

Have you forked phabricator ? Your commit sha (901e3051351dec3c041c683b6d1e718e587e2b4b) is not recognized in this install.

Specifically, the limit is enforced here. You could remove this limit locally if you are not concerned about the usability of the result:

This is not a bug. The element has a minimum height because viewing or selecting text from a tiny element would create usability issues: imagine trying to select 30 lines from the middle of a 100-line block with lines=2.

GitHub returns no results as well, which aligns with my expectation. Do you have an example piece of software that does work like this?

Somewhat related to T4706.

I think we'd have to build another Remarkup rendering target to accomplish that (sending sanitized text-only emails, for example). I also believe we do no policy checks in Remarkup (which is cached).

In T11085#178406, @epriestley wrote:

You're watching #twitter.

Maybe similar to T10312 as well... If we see a test plan, skip the next one?

Expected, though it's going to take me a while to find the dupe.