This is almost certainly fixed by outstanding changes to Herald which are awaiting review. See also T8822.

may be related to a combination of rules.

For easier use:

There are also a number of outstanding Herald Diffs awaiting review, so it's likely some of this is fallout from moderinzing Herald.

Yes, just made a fresh git-pull on it before sending this ticket.
Will PM you.

And maybe more specifics on how I can reproduce the issue, thanks!

I can't immediately reproduce this issue. Can you confirm you're at HEAD?

FWIW, confirming that it also occurs for Firefox 38.0 on Linux Mint 17.

It seems literally broken by half a pixel. If you use a normal display, it seems broken, if you have a hidpi display, its broken by 1/2 a pixel (and thus not noticeable). Assume Firefox is bad at maths.

Oh I can reproduce it on secure.phab now depending on how zoomed in I am.

Just checked on secure.phab on Windows and it does have the same display in Firefox. Looks fine on Internet Explorer.

Windows 7.

What OS? It doesn't look like that on my Mac local or secure.

This report lacks a use case explaining why status columns are useful. Just saying.

Workboards would be a lot more useful if we could do this.

Now that I think about it, one possible explanation is if we're executing O(N^2) queries for each workboard column of N open tasks. (The sum of the squares of the number of open tasks in each column is 2924.)

According to DarkConsole's services tab, query takes 12s overall.

A broad guide for this stuff is available here now:

"Making the effects ... more reversible" is the same as "deleting, disabling or hiding workboards"; they are not separate tasks.

+1 to the ability to delete, disable, or hide workboards.

I'm just going to give our use case for being able to disable workboards. We created workboards on some projects where work was done (let's call it Ops), but after some restructuring (yay) the ops department became split into teams. We still want to preserve the Ops tag to show that the work is ops-related, but we are now using #teamawesome workboards instead. Now issues are showing up as on the (backlog) on the ops-project workboard, while they will actually never be moved on that board. It is mainly a cosmetic thing, but it does cause some confusion for our users as well.
It would be cool if you could disable the workboard - the UI for it could just be that you end up on the workboard page with a text saying "This workboard is disabled" and if you have edit permissions on the project you can enable it again. If the workboard is disabled the column assignments would not show up on Maniphest tasks anymore.
We do not really have a need to remove them from the database, though.

I just updated T8522 with some more information -- we had database issues that night (possibly related to the later corruption, unsure) and I can't repro it.

I'm suspicious that this and T8522 may share a root cause (something else being slow) -- unless T8522 evaporated after the database recovery and seems attributable to corruption or ghosts or something.

At rPee8de4a, this is (mostly) no longer timing out -- but the AJAX request is taking anywhere from 7 to 29 seconds to complete.

Sorry for the delay, we only just upgraded.

This would be very helpful to us during our daily sprints. I described our use case in another ticket before finding this ticket: T8056: Set workboard default filter.

Yeah, I think we can probably slim them down a hair and make them work. Installs that define 200 priorities will get questionable results, but I don't feel too bad about that.

haha, I didnt see your comment. I do think they may eat up space on active, large boards, but maybe it's not a problem. I thought you were the one to originally not want to build the indicators. Visually, we can reduce the UI a bit, no problem.

In T8135#113908, @chad wrote:

I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

I'm not sure what you mean by 'lightly used'.

Broadly the way forward make sense to me.

I think the likely way forward is:

I tried carefully dragging a Low priority task from column A to the bottom of column B where the lowest priority so far was Normal. This still changed the priority from Low to Normal.

Huh weird, our desires for what this feature would do are just complete opposites.

I do this all the time. For example, new conpherence bugs are filed and are in the "backlog" column. I then drag them to "v2" (if I think they are pressing and they tend to be bugs being reported) and change priority at the same time. I don't change priority as often if moving from v2 to v3 but its also not a rare action and its easy for me to just drag it to the right spot to not change priority. <3 <3 <3 this feature :D

Thanks for the report - I did not know about this. :D

In T8135#112918, @btrahan wrote:

See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

Indeed. Reverting .phui-font-fa:before { to .phui-font-fa { in chrome DevTools resolves the issue

Chrome Mac doesn't do this, so I'm assuming it related to D12635.

Following up my previous comment :
This made me realise updates on my chrome were disabled. After re-enabling autoupdates on chrome (latest stable which is Version 42.0.2311.135 m ), the problem still exists.

I get this on this instance with Chrome 42.0.2311.90 m (64-bit) / Windows.

Chrome Version 42.0.2311.90 m

What version of Chrome?

Exact same in chrome

wut

This feature request doesn't describe a problem. Please read the Contributing Feature Requests document for help filing a good feature request.

Sounds like we should just add projects here, and leave the rest for T418.

We don't currently plan to implement this. Instead, we're going to implement triggers. Triggers would let you change task states or projects as they moved between columns, and then you could query by that derived field.

The position: static; in this rule causes the issue:

Let me know if that fixes it when you have a chance? Still not totally sure I've nailed this down but it shouldn't be possible for it to recurse now.

D12511 is a possible fix, although I was only sort of able to reproduce something sort-of similar to the issue you hit.

We are at rPd8ab5f59, which is ahead of rP8efdc4aa.

I suspect I'm just not hitting the right edge case, but this stuff did churn a lot recently so I just wanted to double check that it's definitely not me testing different code.

Maybe it's naive of me to expect that our Monday update actually updated to the then-latest HEAD. Let me check and get back to you.

Just to confirm, you're ahead of rP8efdc4aa? I'll keep digging, but I can't immediately reproduce this at HEAD.

Ah, okay. Yeah, looks similar. I'll take a look, thanks!

Set debug.time-limit to a value like 15 and hit it again? That should give you a trace.