Can you try this?

This will vanish for free when we move to EditEngine, or it could be special cased before that by either:

This one feels a bit un-human-like, although it might be tricky to fix:

I think that's fixed in HEAD now. I pushed it here, let me know if you catch any cases which still misbehave.

Specifically, the issue you're hitting is that [[ x#y ]] and variants thereof generate garbage output?

Yes, this is probably pretty straightforward to implement by mostly copying Maniphest's implementation.

This has been live for a while and appears to be working properly. If anyone is still seeing specific, reproducible problems with cache strategies, feel free to file a new issue detailing them.

I think it's probably correct to fail with --skip-binaries, but it would be nice to preserve that metadata through the process so arc patch can warn you about it, something like:

I think we're good on the actual Phacility flow, seems like users aren't running into the same problems they used to (e.g., confusion about ""test" instances").

It would also be nice to develop an inline version of this for title changes like this:

In T11047#179388, @grindhold wrote:

maybe it would be an option to at least identify lethal arguments for commands and warn the user if he enters some. like rm does when typing rm -rf / without --no-preserve-root.

For completeness, T11107 was also related to this.

Can you file a new bug with reproduction instructions? That isn't expected.

This isn't a use case we're interested in supporting. Phabricator creates the repository in a well-defined location, not a random location.

That isn't a usable root problem description, you've just restated the original feature request.

This creates a problem for absent-minded or new users:

When filing a feature request, we need you to describe your root problem, not just ask for a feature. See Describing Root Problems for help.

I think I figured this one out: it's actually because more than 100 rooms are being filtered. The (`id` < 367) part is being added by pagination code, but won't activate if a user is in less than 100 rooms.

We should fix these, but I think these are fairly self-evident and I think fixing them isn't trivial since I recall declining to fix them the last time I was in this code.

I'm not sure I understand the use case for that. Do you set your client OS to local time, but prefer to use Phabricator in UTC? Offhand, this seems unusual. Do you have any particular reason for doing this (e.g., you live right next to a timezone boundary and change zones multiple times per day)?

I added you to Community, so you should be able to make edits yourself now

Yes, but why?

Specifically, you saw this page, and decided that you were not in the right place?

This should be resolved at HEAD of master. To get it to work you may need to update and then go through the password reset process again.

I'm sure there are still some cases where we don't do a particularly good job, but let me know when you run into them.

I think this one works:

I have no idea if this is MP4 or not:

I'm going to merge this into T6916. That implements a reasonable behavior for application/ogg (assume video by default, allow users to embed as audio instead with media="audio") and browser seem to do fine when audio is embedded with <video /> anyway, so I suspect we'll be in reasonable shape after that and not need to try to determine the contents of OGG containers in a more sophisticated way.

Diffs should be less choppy now, here's the improved version of the above change:

Great, glad things are working now. Thanks for confirming the fix!

I think this pretty much boiled down to three technical pieces, all now better covered elsewhere by more specific tasks:

This is pretty rough (particularly, the actual diff part), but wired up everywhere. HTML email includes a link:

Well, I'll leave this open for confirmation/feedback/etc.

Here's the new AuthProvider code for OAuth2 autologin after D16060:

I'm going to support third-party (as here) and OAuth2 (easy) but we have no use cases for other stuff right now (mostly OAuth1 on Twitter/Jira/Bitbucket, I think).

Yeah, I think something similar to D15961 is reasonable here. It's going to a little bit one-off and weird, but this and the timezone checks are the only cases where we care about client settings, I think.

T10402 is the "check client/server agreement about HTTPS" task.

This was likely fixed by D16052 (June 5th). Can you reproduce the issue at HEAD?

See T9548#139908 for some discussion.

I can't reproduce this. Here's what I did. I set the server timezone to "America/Chicago":

I think this is reasonable to add to date controls in the very long run, but suspect few users routinely create events or countdowns in non-local timezones.

This also reproduced with normal "Edit Projects", it wasn't specific to the bulk editor.

If you come up with reproduction steps, feel free to file a new report.

The safer default generally seems sufficient here.