This is probably happening tomorrow, unless I am just toying with everyone's emotions.

Yeah, this feature was a mistake and the data should never have been disclosed. We consider user email addresses private. I don't plan to expose this information again.

I think I can fix that. The current assumption is that the wrap is the result of multiple words:

This bare "v3" in the is still a little weird:

yeah whatever

》 looks okayish but has weird spacing:

❱ he he he

HOLD ON WE HAVE HUNDREDS OF BRACKETS TO LOOK THROUGH STILL

⟩ doesn't have the bad spacing but does have an odd baseline:

〉 has the bad spacing and also a weird baseline:

〉 looks a lot better, except that it has some kind of bizarre super-wide right margin on the actual glyph, at least on my system/font:

Well, it doesn't look awesome either:

› probably doesn't look that bad.

it's beautiful

This has been live for a few weeks without any issues, and I generally expect it to have nearly zero impact on reasonable workflows, so I'm going to assume the best and close this out.

The WMF-specific aspects of this are covered on the WMF install in https://phabricator.wikimedia.org/T125104, and that looks like it has a promising path forward that doesn't rely on this event. We haven't seen other outstanding unresolved issues and this has been in the wild for about two months now, so I'm going to assume the best and close it out.

This has been live for a couple weeks without making any waves and these changes were all pretty straightforward so I'm going to assume we're in good shape, but yell if anyone bumps into issues.

Broadly, these emails can certainly be improved (see T6600; see also some outstanding known issues like T6576, T7031, T7030, although I think those are non-impactful). The "with context" inlines and inline diffs are particularly bad, but these features are off by default and I believe they generally run counter to the goals of the mail and do not expect most installs to enable them (they exist for a variety of historical reasons, and because some installs have special needs), so they've been fairly far down the priority list.

Couple of quick basics for easily addressable / surface issues:

The behavior is not inconsistent with the documentation, and the documentation does not suggest the configuration you selected.

I was referring to T9973

See also T5118.

I guess "impressum" is the "mesothelioma" of 2016.

Actually, I'm pretty sure @denialgorge's comment is also SEO spam!

Pretty sure that was SEO spam, not just bumbling.

Where's the other request for this?

In your first example, you can likely:

T9657 is probably the relevant guidance. There is no way to get the old behavior back.

This is not a valid Phabricator bug report. Please see Contributing Bug Reports.

I'm not planning to touch all the cases like ` #x, {nav #x, ``` #x, %%% #x, etc. We don't have a client-side Remarkup parser and I'm not planning to build one for this. See T3725#39466 for some earlier discussion.

This currently triggers autocomplete, but probably shouldn't: ` #f.

and also the culprit! hoo hoo hoo!!

It can't currently move to translations or be per-user because it has global effects, notably the availability of "silly" statuses in Maniphest. We can't show different users different sets of available task statuses.

Such a setting already exists: Config → phabricator.serious-business

To be more specific, I just mean:

I'm out of ideas and can't reproduce this problem, then, so we can't move forward (see Contributing Bug Reports). Here's, e.g., this working fine for me against this server:

I think this has served its purpose, so I'm going to close it out. Results:

How are these tests executing?

I'm unable to reproduce this against this host or hosts in the Phacility cluster.

D15173 updates the documentation.

doesn't seem like good practice

Yeah, I suspect that the length of the header is the issue.

In T9348#156791, @exp10r3r wrote:

I tried doing an arc diff to submit my patch but ran into this,

[2016-02-02 21:15:55] EXCEPTION: (PhutilTypeExtraParametersException) Got unexpected parameters: standard at [<phutil>/src/parser/PhutilTypeSpec.php:150]
arcanist(), phabricator(head=master, ref.master=3264d9f680cb), phutil()
  #0 PhutilTypeSpec::checkMap(array, array) called at [<arcanist>/src/lint/engine/ArcanistConfigurationDrivenLintEngine.php:90]
  #1 ArcanistConfigurationDrivenLintEngine::buildLinters() called at [<arcanist>/src/workflow/ArcanistLintersWorkflow.php:44]
  #2 ArcanistLintersWorkflow::run() called at [<arcanist>/scripts/arcanist.php:382]

I could run through it by removing the following section in .arclint file,

,
    "xhpast": {
      "type": "xhpast",
      "include": "(\\.php$)"
    }

But it wouldn't let me commit.

If that's the case, a workaround is to query for the tasks in Maniphest with page size > 865 instead, then "Select All" and "Batch Edit Selected".

Oh, maybe the issue is actually the redirect. Specifically, we'll end up issuing this:

I can't immediately reproduce this by issuing a query for 1,000 tasks, then doing "Select All > Batch Edit Selected". The page takes a couple seconds, but loads fine.

In T10269#156825, @epriestley wrote:

sorry that I can't provide reproduction steps

Historically, I don't think these tasks (error logs with no obvious negative effects and no reproduction steps) are very useful. I don't immediately know what's going on here, nor plan to dig into it unless it creates an observable problem.

Well I don't choose any tasks, I guess it defaults to all objects visible on the workboard (of which there are 865).

How many tasks are you attempting to batch edit?

sorry that I can't provide reproduction steps

(This isn't a once off, there are a bunch of these errors)

(Specifically, the scrolling is a feature which I added in D10188 but punted on making work in Firefox.)