I'm going to merge this into T6072, which discusses some of these issues in greater detail.

There is now a Edit Related Tasks → Close as Duplicate action next to the existing Edit Related Tasks → Merge Duplicates In action in the related tasks submenu. This change is live on this install:

I tried a couple of other devices in the simulator but couldn't get a repro -- can you try this to get a JS trace?

I can't immediately reproduce this in iOS Simulator or on my physical iPhone 4s. What hardware/OS version are you seeing it on?

PhabricatorPasteViewController is the best example for the EditEngine comment thing. Basically, make the comment form generate like Paste does (Maniphest too, although it's more complex). Then you can remove PhamePostCommentController completely.

This is unrelated to prose diffs.

(Leaving this open to remind myself to keep an eye on it.)

D16194 may resolve this. I'll keep an eye on things after the deployment and close this if we don't see any more issues for a bit.

Docs regenerate on a cron so this won't actually show up live until sometime tonight, but D16186 has a screenshot.

Thanks for the report, and for including good reproduction steps.

Thanks for the report, and for including detailed reproduction steps. This should be fixed in HEAD of master, and will promote to stable at the end of the week. Let us know if you run into anything else.

This is probably better implemented as "content" ("content matches regexp...") than the narrower "shebang".

This reproduces for me:

I identified posts on invalid blogs with this query:

Oh, it actually should cause this issue as currently written. I'm just going to destroy the bad data until this appears in the wild in a more reachable way, I don't think there is any easy way to resolve it.

Post #667 has an invalid blog, so this is probably difficult/impossible for normal users to hit, but it shouldn't cause this issue. I'll see if I can reproduce it locally.

• PhameBlog calls delete() on posts directly, but should use the destruction engine to destroy them instead. Calling delete() directly means that edges, comments, etc., on the posts won't be cleaned up when a blog is deleted.

Oh, and we select the correct protocol for custom domains now, but don't enforce it when serving content. That is, these both work, and we always link to "https", but "http" should redirect you directly to "https" instead of serving content:

Few more things I caught:

Thanks, this reproduces for me.

In live comments, these links are bad offhand:

• The stuff above should be better now, but I'm not sure if I got everything. We should run through that list again.
• The "Subscribers" and "Projects" links here do not link to the correct domain, and fixing them isn't trivial because they're event-driven extensions:

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

You can also already filter by repository. Why do you need to group by repository?

This isn't an actionable bug report because it doesn't include reproduction instructions. Reports MUST include reproduction instructions; see Contributing Bug Reports and Providing Reproduction Steps.

No.

This is fine technically, but I'm hesitant about introducing it because it makes the issues in T6522 worse in some sense. That is, this field really means something like:

If we masked with ***** instead of xxxxx, do you think that would have been more intuitive?

I'm not completely opposed to ever changing this, but I think there are pretty good reasons for the current behavior.

This report isn't actionable. Feel free to file a new one that is:

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Basic support to (hopefully) support svnsync is now deployed. The Herald stuff would be nice to have eventually, but we don't currently have any real use cases for it.

From T10610, this can reasonably occur in arc unit subprocesses.

Sites eventually got split out (T5702) so that's no longer an issue, but this still isn't really straightforward. We do a lot of object loads which need some real viewer (blog, post, other adjacent posts, author, subscribers, object references in remarkup).