• Phage is now an ArcanistToolset.
• Every toolset gets <toolset> help/--help, <toolset> version/--version.
• Every toolset gets <toolset> alias, although this is probably broken for everything for now.
• Every toolset gets <toolset> shell-complete, but good luck.
• Aliases can now resolve to other aliases.
• getCommandSynopses() is now getWorkflowSynopses().
  • Return a string or list of strings.
  • Don't format/indent.
• getCommandHelp() is now getWorkflowHelp().
  • Return a string.
  • Don't format/indent.
  • Don't include "Supports: svn, git, hg".
• ArcanistConfiguration no longer exists. Its hooks no longer exist, either:
  • willRunWorkflow() no longer exists.
  • didRunWorkflow() no longer exists.
  • didAbortWorkflow() no longer exists.
  • getCustomArgumentsForCommand() no longer exists.
• The Workflow->didParseArguments() callback no longer exists. Just do the parsing in executeWorkflow().
• ArcanistWorkflow->passedArguments no longer exists (no callers).
• ArcanistWorkflow->getPassedArguments() no longer exists (no callers).

When any configuration source specifies an invalid library, we now prompt you to continue without it if stdin is a TTY. This allows you to fix config with arc set-config --local and similar. If stdin is not a TTY, we fatal.

• Removed arcanist_configuration configuration setting. This is a legacy/FB-only option which doesn't fit into the roadmap.
• Removed --conduit-version. We do capability testing, now.
• Removed --conduit-timeout. Not clear this ever really had any callers.
• Removed --skip-arcconfig. Unclear what this was for. FB only option because someone created an invalid file at /home/.arcconfig?
• Removed --arcrc-file. Unclear that this had any real uses. Potentially open to restoring this or similar if there's an automation/bot use for it.
• --config and --load-phutil-library must now appear before other arguments.

Current state of the world here is:

This is promoting soon and we seem to have come through it without too much damage. T13095 is a followup for style="..." attributes.

That's likely everything for this week.

Resolved by D19163 etc., see T13088.

Effectively resolved by D19167; see T13088 for followups.

I'm not currently planning to build this, per se. See T13088 / T6139 for lighter-weight support around log summarization.

Likely resolved by D19166, see T13088 for followups.

Also relevant:

(For completeness, this came up via the support queue in PHI411.)

Add line numbers and links to the log page with proper copy/paste behavior.

Add line numbers and links to the log page ... This is actually legitimately hard without scanning the entire file. Maybe we can emit a map as part of finalization which shows which has line markers every megabyte or so.

These changes are all deployed here, now. The embed element only got touched lightly but is at least slightly better. See T4340 for further adventures in Content-Security-Policy.

• "Download" is a form, so you can't command-click it.
• The whole thing is a <div href="..." /> (huh?) so you can't command-click it to open it in a new window.
• When you click it for a non-image file, you get this weird interstitial that you can leave comments on if you click an additional button, which uses janky animations and AJAX. This feature is pretty half-baked and I've never seen anyone actually use it. It's possibly a net negative in its current form.
• There is no way to actually show the text file in the browser! ARHGRH

Okay, here's another one of these:

Maybe summarization and highlighting aren't the same object?

On the Stripe payment processing workflow, we embed a piece of Javascript directly from Stripe.
On the Recaptcha flow, we embed a piece of Javascript directly from Google.

Other stuff to test:

When we use a Quicksand transition from page A (which does not have Google or Recaptcha stuff on it) to page B (which does), the CSP from Page A will currently still be in control and prevent Page B from working.

On the Stripe payment processing workflow, we embed a piece of Javascript directly from Stripe.

I don't think this exposes new attack surface, at least today.

Idle thought: can we data: an SVG with onhover behaviors?

Idle thought: can we data: an SVG with onhover behaviors?

(Offhand, it's actually not immediately clear to me whether unsafe-eval applies to style attributes or not. Presumably, it should. This is easy to test.)

We use data: URIs to inline small images into CSS. For now, I'm going to allow these unconditionally. It's possible we could be more strict in the future, and allow data: as an img-src only in CSS files.

We use inline style="..." attributes and can't realistically get rid of these in the short term. Although some of these are just laziness in obscure interfaces, quite a few are legitimate (for example, inline background-image for profile images, and inline computed width or position values for elements which can be moved or resized in Javascript). We could move more rendering to Javascript, but Phabricator "mostly sort of" works with Javascript disabled and I generally think this is desirable, so I think this would be a tradeoff, not a strict improvement.

From PHI399:

Okay. For the sake of 100% clarity it would be nice if the timeline story did show why the action was taken as it isn't immediately clear (unless you've read the documentation of course) why it was removed.

Very rough version of the new log:

See T13092; tangentially, it might be nice to render these stories more explicitly as "X added Y, removed Z (because Z is a subproject of Y, and objects may not be tagged with multiple mutual ancestors/descendant projects)", if some sufficiently terse phrasing can be found.

I'll make a note on T12455, but we might be able to render this timeline story more clearly, e.g. "X added project Y (which automatically removed Z, a subproject)" but I think this is likely fairly natural/obvious in most cases and I'm not sure if it's trivial to completely explain in the timeline.

Ah, that would certainly explain it. Sorry for the noise - when entering this I did wonder if I had missed something as it didn't make sense that a name collision would be able to cause this.

"Plasma on Wayland" is a subproject of "Plasma".