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:

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.

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

The second issue causes the error #1054: Unknown column 'epochModified' in 'order clause' (note no ft_doc) which isn't exactly the same as the first issue.

I think this is a couple of different issues:

When you use the "Query" field to activate Ferret fulltext search, a "Relevance" score is computed internally. Roughly, today: documents are more relevant if your terms appear in the title than if they appear only in other fields; and stemmed terms are more relevant if the exact term you searched for appears in the raw document than if the stemmed version appears in the normalized version of the document.

PHI379 describes a weird "Copied Lines" signal which can at least be triaged.

this is a very good task :)

haha

I suppose welding does normally take a long time.

Testing any of this is also a pain right now, so before any of that happens I'm going to write bin/harbormaster build --log output.txt or bin/harbormaster write-a-log or something. This overlaps the actual API-writing request in T9124, but that has more complicated concerns (like UTF8 issues, writing to a closed log, etc).

maybe a "grep" would be nice

I'm planning to tackle the build log stuff first since it's the most clear-cut, all fairly close together, and also roughly the most dumb.

The build itself can do this over Conduit. Although it's possible we'll support things like this some day, I think this is currently too niche and disconnected from other application behavior to pursue in the upstream.

See PHI385. I think I stabilized the dashboard arrangement issues in D19123, but the arrange workflows are still in somewhat rough shape.

That is, we mutated the object outside of the Editor, then relied on the Editor to save the mutation.