The actual support issues were likely addressed or obsoleted by the above changes. The rest of this is still planned, probably won't move forward any time soon.

I had a lot of stuff come up this weekend, but made it through Kitava A5 with a Tectonic Slam Facebreakers Juggernaut (???) and an Arc Totem Hierophant, both around 51. Unsure how I currently feel about either character. I think I can turn the Juggernaut into Molten Strike if I find a decent weapon. Damage is okay so far on the Hierophant but my Haku is still at level 1 so fixing his resists has been tough.

I don't know how to reproduce this.

See T13098. I currently plan to expose the shell-complete workflow to every arc toolset, but I don't think being able to shell-complete bin/storage upgrade or similar is worth pursuing.

See T13098 for followup. Currently, I have ArcanistWorkflow generating a PhutilArgumentWorkflow but not actually subclassing it.

This has seen little interest so I don't currently plan to pursue it. Ideally, lint messages should simply include patches so that arc fixes the errors itself.

• 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.