I work on Phabricator.
Oct 16 2019
(See https://discourse.phabricator-community.org/t/website-specifies-emoji-font-in-body-tag/2139/ for the upstream position on this -- basically, that this is bug with EmojiOne/JoyPixels and they should not replace font X with "replacement" font Y when font Y defines a substantially different set of glyphs from font X and changes behavior when it replaces it.)
Oct 9 2019
Sep 27 2019
(That change is from 5 seconds ago so this would just be something to keep an eye on for the next deployment.)
Ignore me if I have no clue what's going on, but I added another call to this method in https://secure.phabricator.com/D20842, which may need adjustment if you've tweaked it (which I think is what's going on here, per rPHABae334e4589a0413c1eb8a9e8d993e553bfeff478).
Sep 13 2019
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.
Sep 12 2019
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.
Sep 11 2019
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:
Sep 9 2019
Filed upstream as https://secure.phabricator.com/T13409.
Sep 3 2019
You kinda answered your question. I can ask "someone", but who is that someone?
See also T211498.
Sep 1 2019
if you use the 'move on workboard' option it does nothing. That is what I missed. Is that the intended behaviour?
Aug 30 2019
See also some discussion in T187256.
Aug 22 2019
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: