The upstream phabricator[2] might also go away though I don't think that is quite as imminent.

It's perfectly fine to configure cluster.databases with one service, and Phabricator internally (in effect) builds a one-service cluster.databases configuration (by looking at mysql.user, mysql.host, etc) if your configuration is empty. Swapping from mysql.user to cluster.databases causes (or, at least, should cause) no change in behavior -- and is happening behind the scenes anyway -- it just gives you access to the persistent flag.

When:
[ Projects ][ include any of ][ X, Y, Z, ... ]
Take these actions [ only the first time this rule matches ]:
[ Send me an email ]

I suspect you're seeing that because when you reload a page by issuing a "Reload" command in your browser, most (all?) modern browsers interpret that to mean "Reload the page, skipping some/most/all caches". That is, the cache behavior of these sequences differs:

Eventually Phabricator ran out of local sockets (30k limit):

We need an easy way to tell logged-out traffic apart in our caching layer.

I'm happy to take a look at this if someone with access has a chance to figure out where it isn't working on your end -- my expectation is that it's supposed to work, but I could definitely have overlooked something.

In some cases, you can currently do something similar with "Mail Stamps". Mail which mentions you is stamped with mention(@username). The stamp appears in the X-Phabricator-Stamps header, or in the mail body if you set Settings → Email Format → Send Stamps to include it (this is mostly for Gmail, which does not -- or, at least, did not at the time -- have client rules to support filtering based on headers).

It [the yellow highlight] was nice to bring the user's attention to the specific comment they were being linked to.

See https://secure.phabricator.com/T13476 in the upstream.

(This doesn't seem to be related to Phabricator.)

I added a hint about this to the upstream in https://secure.phabricator.com/D21209.

This error got a little stricter recently so it might crop up more often after the next upgrade, and it's normally hard to hit by accident so I don't mind being more verbose in handling it. I can add a hint to the error message, something like:

Sounds good. It would be nice to make the parser more flexible here and allow, say, [[ X | aaa **bbb** ccc //ddd// eee ]] to render a link with bold and italics, or possibly let [[ X | {icon ... color=green} qqq ]] and similar work to render a link with an icon, but these feel like pretty small nice-to-have improvements and they'd be fairly complex to implement.

This was changed to fix a security vulnerability, see https://secure.phabricator.com/D20937.

Ah, yeah -- I suspect the patch with the forked highlighting/display behavior should carry over to Ferret without significant changes. This is also still behavior I plan to bring upstream in some form, I just wasn't satisfied with my initial stab at it back in the day.

If you do this:

(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.)

(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).

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.

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):

This is referenced upstream by https://secure.phabricator.com/T13411 and "resolved" upstream by https://secure.phabricator.com/D20806.

This is referenced upstream by https://secure.phabricator.com/T13411 (and, earlier, by https://secure.phabricator.com/T6802).

I believe this is resolved by https://secure.phabricator.com/D20797.

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:

Filed upstream as https://secure.phabricator.com/T13409.

You kinda answered your question. I can ask "someone", but who is that someone?

See also T211498.

if you use the 'move on workboard' option it does nothing. That is what I missed. Is that the intended behaviour?

See also some discussion in T187256.

I filed this upstream as https://secure.phabricator.com/T13378.

This should be resolved upstream by https://secure.phabricator.com/D20704.

This should be resolved upstream by https://secure.phabricator.com/D20703.

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.

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.

See also T190342 and T224082.

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.

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

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:

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.

I've filed this upstream in https://secure.phabricator.com/T13340. See that task for more details.

This should be resolved upstream by https://secure.phabricator.com/D20644. The two changes noted above were similar, but didn't completely resolve this.

I think this will be substantially improved by the upstream change in https://secure.phabricator.com/D20636, which separates these actions:

Thanks, this should be resolved upstream by https://secure.phabricator.com/D20624.