Yes, I know. I also know bugs can get buried or resolve themselves over time (seen both), so since this is a bit old, I'm just confirming on stable for reference. Take your time. :)

Yep, we'll close issues once we resolve them.

Confirming that this bug is still kicking in the latest stable.

Ah, thanks! I think you are right, that is the problem.

This was almost certainly fixed by 5a723bf (D14991 / T10116) on January 11.

Peculiar -- this behavior doesn't exhibit here, but I just did the same thing of removing a subscriber and using Cmd+Enter (screenshot of that: https://www.dropbox.com/s/qp8tyxrh7mq86xa/Screenshot%202016-02-02%2007.07.46.png?dl=0) and the action was not taken.

We're using 2015 W52 -- I checked the changelog since, didn't see anything that seemed relevant.

I have encountered the same issue in one out of about 7 projects. The only thing i seems to remember doing is setting it a few times to different pages while it was working, until it stopped.

Perhaps Phabricator should integrate with this node api?

Good starting point can be found here: http://facts.randomhistory.com/interesting-facts-about-cats.html

Thank you.

Ok, thanks, note that this problem is probably the same as this one: T7260
But it seems to be easily reproducible with linux repo.

Nevermind me, Google suggests IPv6 a pain in PHP

FWIW I'd be happy to trade performance for security by obscurity aka Facebook model etc... when it comes to files stored in Phabricator - because right now on Phacility, the current approach makes wiki pages with numerous image files feel slow since images are not cached at all. And we don't have anything that sensitive. Maybe a config setting could allow this?

Which server log are you asking about? I have looked around at various logs and can't find any errors, but maybe I'm not looking in the right place. I see the GET and POST commands, both returning 200, in the nginx logs and that is it. Nothing in syslog.

What version of Phabricator are you running?

• Do you see any errors in the server log?
• Are you sure about adding @v1.2.15 to the clone uri? I've never seen this before.

FWIW, PHP 7 is not yet supported.

I'm using PHP 7.0.2 with nginx 1.8.1, and running Phabricator at HEAD:

Not sure if lisk should interpret "false" as "null" in this case?

Correct... I'll dive into that. Although it doesn't look like its a quick/simple config change. I'll report back when I have it running.

It sounds like neither of you have actually configured Phabricator's real-time infrastructure. See:

I'd like to not have the users drop back to other means like hangouts. I was happy to wind down the rocket instance, but I might have to bring it back if there are situations arising where real-time coms are required.

In T10257#156493, @epriestley wrote:

Broadly:

• You only need to run arc liberate when developing Phabricator itself (e.g., writing Phabricator extensions or otherwise modifying Phabricator).
• The one ARM system (the Raspberry Pi) we have other direct evidence of users attempting to do installs on is explicitly not supported as a Phabricator host platform -- see Installation Guide. You can try, but you're on your own.
• If you're using an ARM system that could, in theory, broadly qualify as a "normal computer" to host and/or develop Phabricator this is something we might eventually look at supporting, but we don't currently have any evidence that anyone else is trying to do this. We are vanishingly unlikely to dedicate resources to ARM support for the benefit of only one user (if you are developing on ARM hardware) or one install (if you are hosting on ARM hardware).
• If you did read the "Installation Guide" and believed ARM hardware to reasonably qualify as "a normal computer", we can add additional language to make it clear that ARM is not included in what we consider "a normal computer".

This task has morphed a bit, so clarifying the current intent. If you're interested in Sprint/Milestone support, which is actively being built, please follow T9378, T3670.

I can reproduce some variant of this locally by following these steps on OS X:

Ah, thanks. I think this is almost certainly related to your keyboard layout and how we're detecting that you typed "@".

I tried it again with a fresh win10 install and the latest chrome version. Again no username autocompletion.

I cloned Linux and examined the commit, but couldn't immediately see anything wrong with it. I'll do the full import when I have a chance.

I don't think this is a good use of Tokens, which are primarily built for providing Phabricator with flavor. Your request is better suited for Facts (see T1562).

There are some errors in the log, but they seem unrelated:

In T7755#156496, @storrgie wrote:

[...]. It currently feels like you have to _send_ a message to get the updates in the chat room.

Lorem Ispum Testum Thisum Tagums. Differential Public & Media Relations Design

Anything in your PHP error_log?

Unfortunately it doesn't. I get the confirmation popup in a separate window, click Make default and I am redirected to the settings screen without the setting being saved.

Migrated over from rocket.chat (to pick up all the other awesome things within phabricator) and this is one of the first 'issues' I'm seeing with users. Almost everyone is connecting from Fedora 23 boxes with the latex Firefox release (44). It currently feels like you have to _send_ a message to get the updates in the chat room.

@OCram, do you have an non-US keyboard?