I work on Phabricator.
Fri, Sep 13
Nice! Thanks for everyone's help hunting this one down, this was definitely one of the most bizarre bugs I've ever run into.
Since the downsides are fairly minor, I've landed the workaround above into the Phabricator upstream in https://secure.phabricator.com/D20812.
Thu, Sep 12
There's technically a transaction history on Settings, but it's not useful today since the stories don't render properly (only @MZMcBride will be able to see anything here):
I believe this is resolved by https://secure.phabricator.com/D20797.
Wed, Sep 11
I upstreamed this here:
Here is a simplified document which freezes Chrome 77:
Broken in Chrome:
There's nothing special about that task
Here's a view of the board with exactly one task that freezes in Chrome for me:
Here's what I'm observing:
I think that's just "the freeze is after WorkboardDropEffect.js" is loaded. All the class definitions load first without actually executing anything or causing side effects (like JX.WorkboardDropEffect). We seem to make it through this part okay, and I think that's what you're seeing.
Yeah, this is wildly difficult to debug with Chrome's tools. The profiler freezes and I can't get it to unfreeze, stopping execution freezes without breaking anywhere, and when the window freezes the entire window locks up so you have to close it. This discards all your debugger state, and you have to open a new window, reset all your debugger state, then load the page. This isn't even very helpful since breaking on DOMContentLoaded doesn't get anywhere.
Aha! I can reproduce on "Growth-Team", just not the original "Language-Team" project.
This loads okay for me in Chrome 77 on macOS 10.14:
Mon, Sep 9
Filed upstream as https://secure.phabricator.com/T13409.
Tue, Sep 3
You kinda answered your question. I can ask "someone", but who is that someone?
See also T211498.
Sun, Sep 1
if you use the 'move on workboard' option it does nothing. That is what I missed. Is that the intended behaviour?
Fri, Aug 30
See also some discussion in T187256.
Thu, Aug 22
Aug 15 2019
I filed this upstream as https://secure.phabricator.com/T13378.
Aug 8 2019
This should be resolved upstream by https://secure.phabricator.com/D20704.
This should be resolved upstream by https://secure.phabricator.com/D20703.
Aug 2 2019
This is moderately technically complicated, the use case isn't clear to me (why is it important to access the footer on these particular pages?), and making this change on full-screen interfaces would cannibalize screen space. I suspect that users are very rarely interested in accessing the footer from workboards and would generally prefer the extra space for showing cards.
This should be resolved upstream by https://secure.phabricator.com/D20695.
The misleading messaging has been fixed upstream by https://secure.phabricator.com/D20694.
Aug 1 2019
This is expected: since https://secure.phabricator.com/D14853, we've explicitly hidden these stories from feed and mail under the rationale that they are universally uninteresting.
This is technically covered under the umbrella of https://secure.phabricator.com/T8952 upstream.
I suspect this was resolved by https://secure.phabricator.com/D20455, maybe?
I think this was effectively resolved a while ago, there's a little edit icon next to the selected board now that lets you jump to the edit view:
I think this was implemented some time ago ("Move tasks to column..." from the workboard column action dropdown).
Just bookkeeping -- this is upstream as https://secure.phabricator.com/T7593.
I'm not a big fan of how this currently looks/works, either, and generally agree with all the feedback here. There's no specific upstream task for fixing it (and there are a few related things I want to look at) but I intend to change how this interaction works the next time Files gets an update.
This is a bit old, but I can't reproduce it against the currently deployed version of Phabricator on this install in Safari, Chrome, or Firefox. Not sure if it got fixed upstream or the Paste changed or if I'm just doing something wrong.
Upstream, this is https://secure.phabricator.com/T11502.
This guidance is out of date and a bit misleading. I filed https://secure.phabricator.com/T13364 upstream to update it.
I noted this on https://secure.phabricator.com/T13339, which is not exactly adjacent but sort of has similar flavor and is somewhere in the pipeline.
(To throw another one on the pile, T168061 is also closely related, I think. I'll add some details there shortly, none of these are exactly copies of the others even though there's some overlap and a lot of commonality in the root causes.)
That's already how things are working right now -- this task ("Tags" working differently in Maniphest vs Global search) and T224082 (query term "X\Y" working differently in Maniphest vs Global search) are both because the Ferret and Elastic engines are doing different things.
I think this is largely similar to T224082: the Elastic engine does not resolve the "Tags" query constraint in the same way that the builtin (approximately, Ferret) engine does, so searching for "Project X" in Maniphest means "Project X, or any child of project X" under the Ferret engine, but means "Project X exactly" in global search under the Elastic engine.
Blame loads asynchronously, so my expectation is that it does not slow the loading of the contents of the page.
This was changed upstream in https://secure.phabricator.com/D20122 so we automatically focus the first "Username" field on the login page.
This should be resolved by https://secure.phabricator.com/D20693.
I think I can reproduce this sometimes. I filed this upstream as https://secure.phabricator.com/T13363.
I believe this upstream in https://secure.phabricator.com/D20648.
Jul 18 2019
This is expected behavior, but not exactly desirable. See https://secure.phabricator.com/T8952 upstream for some context.
I'm not sure what the purpose of the cookie is...
Jul 17 2019
Ah, good catch. Yeah, files.viewable-mime-types is likely the culprit here.
One of these is detecting as MIME type video/ogg; one as application/ogg. The files.video-mime-types configuration option in Phabricator includes both of these MIME types by default, but it may have been adjusted on this install to include only one. If so, a simple remedy might be to add application/ogg to files.video-mime-types, if there isn't some reason that it was removed/disabled and I'm guessing right about what's going on here. Locally, with the default configuration, this file embeds with video player controls for me:
Jul 15 2019
My expectation is that you need "Can Configure Application" on the Maniphest Application to edit Maniphest forms, and so on:
This is linked elsewhere in connected tasks already, but I believe the upstream change in https://secure.phabricator.com/D20647 should fix this.
I think Auth → Customize Messages → Login Screen Instructions should now let you configure this. I expect this approach should prove more stable than the older approaches.
I believe this install is currently configured to use ElasticSearch for global search. Search in other interfaces (including Maniphest advanced search) is powered by Phabricator's builtin engine, "Ferret".
Triggers currently only activate when a task card is dropped into a column with triggers (see this comment for details). They don't impose a global performance cost like Herald, and act on behalf of the user moving the card.
Jul 14 2019
I've filed this upstream in https://secure.phabricator.com/T13340. See that task for more details.
Jul 10 2019
This should be resolved upstream by https://secure.phabricator.com/D20644. The two changes noted above were similar, but didn't completely resolve this.
Jul 3 2019
Jul 2 2019
I think this will be substantially improved by the upstream change in https://secure.phabricator.com/D20636, which separates these actions:
Jun 29 2019
Thanks, this should be resolved upstream by https://secure.phabricator.com/D20624.