(I'll follow up on this once I have a chance to bang on it a bit, but I want to try to finish up the RRULE stuff while it's still somewhat fresh in my mind.)

This went out a while ago and I confirmed the fix in production.

I'm going to presume we got this, but reopen or yell if you're still seeing issues on the new code.

Thanks for the report! The detailed reproduction instructions were very helpful in resolving this.

I'm also not sure if we can use SVG as a data: URL in CSS. It probably should work, but if it doesn't we'll have to rasterize (and, I guess, serve 5+ different sizes to every user).

Alright -- we can have bin/celerity map rasterize SVG into arbitrary sizes if I'm not comfortable serving SVG directly from Celerity.

• Create a badge.
• Award it to a user.
• Visit their profile page.
• On the profile page, the badge title should link to the badge detail page (currently: no way to get to the badge detail page).

I'm not really sure this is actually useful given that every method is now named <application>.whatever and you can search by substring.

(That will give us slightly bad scale-downs on 1X screens, but I bet they're not worse than scaling down an SVG would be.)

I think we can just do 2x in all cases for these, if that's reasonable?

This one is a little scattered, so let me know where I can fill in any gaps. Most of the details are in D16178.

Do you have any use cases which are not approximately some flavor of:

I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

@chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

How can I reproduce this locally? See Providing Reproduction Steps for help on providing reproduction steps.

To accept this report, we need reproduction instructions we can follow to reproduce the issue locally. See Providing Reproduction Steps for details.

I think this is entirely reasonable.

To actually add a remarkup rule, the basics are simple:

I think this didn't actually get handled in T10262, but should be doable now.

Unicode has a page of heiroglyphs but they don't seem to be supported yet on OSX.

This is probably 5 minutes of work, I am just incredibly unreliable.

Actually, I don't think we can really style the numbers of a numbered list independently of the rest of the list. They aren't directly addressable with CSS and the approaches I've found for doing it rely on using counter(...), which I think is unreasonably complex for this use case:

I can't reproduce this. Here's a diff with a new file:

Ah! Thanks, we'll get this fixed.

See Contributing Bug Reports if this is intended to be a bug report.

Does raising max_connections in /etc/my.cnf (or similar) and restarting MySQL resolve this?

GitHub also does this:

We made one change recently (T11672) but that should cause us to use fewer connections.

Please see Contributing Feature Requests for help filing feature requests. Thanks!

This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.

I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!

Presuming resolved by D16584. Thanks!

I've banged on this a reasonable amount locally without issues and the originating instance reports that this seems to have calmed things down in production with these patches, so it seems like this pretty much just worked.

There's a bunch of other Herald stuff we already do for this field so I'm just undoing the change from D14766, at least until someone complains that this field type isn't using the search logic they expect.

Yeah, go ahead and submit a patch. Thanks!

I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.

To fix:

We don't normally accept bug reports on prototype applications (see Prototype) but this is a one-line fix.

To fix this:

This isn't a bug in Phabricator, then. Please review Contributing Bug Reports and Support Resources carefully for details on what we provide support with.

On the cache:

I think this is the CSS that tries to cut off the titles interacting weirdly with other table CSS.