I think a workaround is to swap the particular changeset into unified mode (View Options → View Unified) and then interact with the comment, but the fix seems trivial and straightforward.

Thanks, I can reproduce this as well (e.g. D15565).

D14879 made hovercards smart about these sort of things (But hovercard don't have a little arrow thingy).

sorry, forgot to say it's this document https://secure.phabricator.com/book/phabricator/article/arcanist_lint/

I always see it like this (Chrome/Windows); I've dug a little in the algorithm, and I think it's using location relative to the page for the calculation, which is why the first (top-most) tooltip acts differently than all the rest.

I think these steps should reproduce the issue:

How do I reproduce this error?

D15545 should fix the infrastructure part of this, and make this error more clear by returning an explicit diagnostic error rather than a mostly-working string and a log.

Oh, I believe the actual issue is that the translations are variant on the wrong parameter. I think this is the correct fix (adding an extra array()):

D15544 (changing %s to %d) shouldn't be the fix for this -- %s is correct, because we want to render "1,234,567" if the number is large:

Are you always seeing this render in a bad location or is it only sometimes? I regularly see the first rendered hovercard located way off to the left but it's only the first hovercard that tries to render -- and it's usually only the first hovercard after starting up Firefox. I haven't found reproducible steps so I haven't bothered to report it yet, but I wonder if it's related to this. I primarily use (the most recent) Firefox so it may be just browser. Using Cmd/Ctrl+Refresh doesn't cause it to affect again - manually restarting Firefox is also not a surefire way to reproduce.

D15535 should completely fix this in all cases

Evidence for the trial (when the fix goes live the description will render correctly)

It was another cspeckmim

u wot m8? havin' a go? havin' a little laff?

A generic Phab icon would be fine for a first pass at improving this IMO.

At a minimum, Herald, Harbormaster, Nuance, Phortune and Differential can author stories today, although not all of these stories currently render with photos. We should probably assume any application may author stories.

See also vaguely-related T8952.

This report does not include reproduction steps. Bug reports must include complete, self-contained reproduction steps to be accepted by the upstream. See Providing Reproduction Steps for help.

I think you are missing some steps, like that you need to set the edit policy to something fairly restrictive. @richardvanvelzen is correct though, you can unlock this from the command line and archive the project. You can also use bin/remove to permanently nuke objects, but it's not recommended.

You can probably use bin/policy unlock to open up the policy.

Sounds good, let us know if you run into anything else.

Latest version seems to have fixed this. Sorry for the noise, and thanks for building such an awesome software.

For completeness, T10651 is the earlier report.

I think this should now be resolved in HEAD of master. It will likely promote to stable in about 24 hours.

(fantastic bug reporting, otherwise)

I think that stuff isn't linking because someone is pushing their own branches to the upstream staging repository, making the commits ambiguous. That is, e3f89279f912 is ambiguous as either rPe3f89279f912 or rSTAGINGe3f89279f912.

rPe3f89279f912 should have resolved this, I believe.

Doh. Give me a minute, testing with 3493d9d5138e0a630624bced548090163ce9be8a now.

Your install is out of date.

Ah, thanks! To hit this, I think we need to push a mixture of changes:

I've cloned the repo to a test machine, so I'm available to make more tests if you need

I've rolled back my state to better identify the steps.

The only way I can see to get to an error state is if both branches had the same head before the push? I'm not sure how to build that state, although maybe I'm just missing some subtlety of hg branch or some sequence of merge/close operations which can force it.

Using mercurial push a set of commits that updates multiple branches at the same time

Ok i found the reason for the problem.
If you set Applications → Projects → Edit Policies → Default View Policy to Project Memebers i does not work. You can still create normal projects and subprojects but you can't create milestones. I think that is because milestones do not have members but the permissions are evaluated against the "project members".

This isn't a valid bug report. Please see Contributing Bug Reports and Providing Reproduction Steps.

Thanks for your message. Yes it was a server issue with Apache 2.4. Acces was denied. It's ok now.

This error for a new installation is usually do to a mis-configured webserver redirect. If you are using Apache, make sure to place the rules in httpd.conf or similar, not .htaccess.

This report does not include valid reproduction instructions. These instructions are required; see Providing Reproduction Steps for help.

Ok, then I'll investigate further and give feedback as soon as i've found something

No luck, I tried the same settings you just posted, an admin as edit policy, also in the group view and join policy. I couldn't reproduce your screenshots.

Yes I'm member of all those groups as described above. I'm also an "Admin"

I don't know the relation of your account to those policies. Are you a member of those groups?

I've posted a screenshot of my settings or do you need anything else?

Generally easier if you just tell us what your settings are that reproduce the issue, rather than us try to reverse engineer all the choices.

Yeah i did basically the same. What are the permissions of your project?

I can't reproduce this. Here's what I did:

PHP7 is using APCu. For those in need of APC (backwards compatibility) stuff - there's https://pecl.php.net/package/apcu_bc / https://github.com/krakjoe/apcu-bc

ATM, PHP 7 is not officially supported; See T9640. Your best route forward is to use PHP 5.