Do you want to give me four colors that work well for you as a starting point, by, e.g., control-clicking an existing diff and fiddling with the CSS?

Better - are keywords/classnames red? I think for me reds are duller, so they look very similar to the plain black text - brightening that would help.

Prose:

Better? Both just look grey?

Sorry I mean indigo

😺 😺 😺

pink / slightly different pink incoming

Yolo

@chad, I don't mind doing the legwork on this if you're OK with a separate mode.

:( Maybe this is more isolated than I thought - I can probably make do with a stylish extension for now (if the blue/orange mode doesn't work). For what it's worth I find github's colors pretty readable, seems like a useful reference to me.

I think we should just revert to the old colors and put a blue/orange mode in Settings → Display → Accessibility, since no one seems excited about doing the legwork in T12060 to pick other colors.

We recently darkened that color in T12060 to improve the UI for colorblind users, and the change was specifically vetted by a colorblind user (although maybe not a colorblind engineer who uses Phabricator? T12060#205789).

😿

We had "full new lines" light green for all of a week before @epriestley stole my kittens until I changed it back.

Versions:

phabricator a4f8aff2a2e41e5853488689c9d79ee425482fb9 (Sat, Jan 14)
arcanist ade25facfdf22aed1c1e20fed3e58e60c0be3c2b (Thu, Jan 5)
phutil 9d85dfab0f532d50c2343719e92d574a4827341b (Thu, Jan 12)

I would guess that we should:

Yeah I don't know what to do with this task. We've made two separate changes to colors in the past 2 weeks at the request of a color blind user. This change would be the third request.

What version of Phabricator are you using?

I just tried again (reloaded tab first) and didn't see the issue... Which is puzzling because I had reloaded the page twice and saw the issue twice before filing this bug.

I can't reproduce this. Here's what I did:

This is all frozen until we sort it out more generally.

@epriestley I like the work going on to externalize the linters, and I understand why you would merge the tasks.

I upgraded last Friday to 2604c5af55f654d36f8db2f080b96486c4572216, so far this exception has not popped up again. I will check again later in the week.

Ah I guess it was a custom query - I checked someone else's dashboard who I know shows audits and theirs did not have the same issue as it was using a built-in one. Thanks for explaining, I can see how migrating a saved query would be difficult/impossible with no major benefits. I had never come across that type of error showing on page like that before and just wanted to check.

🐕

is that expected for this?

perfect thanks!

That error makes sense,

• Ubuntu 16.04
• PHP 7.1.1
• nginx 1.11.9
• Galera Cluster MariaDB 10.1.21

See also http://news.php.net/php.bugs/201680

Can you provide system information, since you're saying this is a system (7.1) issue? I'm not able to currently reproduce this bug.

I just got this email from Google Cloud:

I upgraded to 5efbf4d74aa72c5a7d7f161ea8c5aa33ac0e3189, after which when navigating to the list of audits on dashboard I get an error:

Exception: Query "need" is unknown to application search engine "PhabricatorCommitSearchEngine"!

The dashboard panel used the "Needs Audit" query (I believe was at least based on a default query) - is that expected for this? After modifying the dashboard to use a new panel using the new "Active Audits" query the dashboard correctly shows the results.

(Upgraded from 5efbf4d74aa72c5a7d7f161ea8c5aa33ac0e3189)

Confirmed this is fixed after upgrading to 864d3984ebdb42b9a2670103ca3607342e46b7dc

More or less ran into first issue with Q444.

I think we can just offer more options in ProjectMenuItem

This has come up again with a slightly different use case. We want to intelligently purge tags from our staging areas. To do this, we examine refs/tags/* in the staging area, and parse out the diff IDs. It would be great if we could do this from differential.revision.search, but the attachments/constraints don't support it. The current working approach is differential.querydiffs with the IDs, parse the revision IDs out, then differential.query to get the revision statuses and their associated diffs list. This approach allows us to make significantly less queries than examining *all* closed/abandoned revisions, then calling the frozen/deprecated differential.query for the diff list.

We could do some URL magic in JS to add ?fullscreen=yes to the URL bar when you activate the fullscreen mode, then respect that. However it will take 75 hours.

A quick word to express my satisfaction about the new personal menu: after some days, it becomes standard practice on two instances I use to access current sprint workboard from the menu.

I plan to look into this stuff after new home settles

In T12139#208563, @chad wrote:

If you're on linux, I think emojione extension likely only choice. What OS/Browser?

The buckets now in Audit also make the count confusing, before I think it was all open audits, but now we break them out like in Differential. Maniphest makes some sense, but not really in any actionable way. I think Nuance though, we should have some sort of count since the goal of that product is "inbox zero".

Yeah that makes sense. On mobile you don't get the dash but in that scenario you're probably wanting to look at most recently activity and not so much of "what do I have to do today".

Home should be "stuff I need to address". I don't think per-app "counts" really solve anything at this point with customizable dashboards.

Would it be the same effort to show that there are any vs. no items needing addressed?

In T12163#208938, @epriestley wrote:

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

I'm just going to rename Differential everywhere.

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

typeaheads are useless

Our DBAs are currently in the process of testing the a patched mariadb package. I will try to keep you posted on that progress but it looks like the fix is now backported to 10.0

(I think this only impacts Diffusion, not Differential.)

For completeness, the "20 other subscribers" dialog displays disabled users in a different, unique way that isn't like any of the other ways (grey, no dot, no strikethru):

I'm going to merge this into T12164, which I think is a more powerful approach on this.

In Paste (and I think Differential), we scroll lines instead of trying to wrap them: