Page MenuHomePhabricator

Dragging tasks on Maniphest appear in the wrong position (n+1)
Closed, ResolvedPublic


Hi Team.

When dragging a task on Maniphest it appears properly, but after a page refresh it is shown in wrong order.

This is the behaviour (all in the same priority)

If moved up, it will be moved n+1
If moved to the top, it will be placed at the end of the current priority list.
If moved one position down, it won't appear as moved.
If moved down more than one position, it will move n-1 positions

Changing priorities works as expected.

I've updated the code at the latest current revision and it is not fixed.

This started to happen with code introduced this month. Probably between March 1st, 2015 and March 7th, 2015.

Let me know if I can provide more information to troubleshoot this issue.


Event Timeline

nicolast raised the priority of this task from to Needs Triage.
nicolast updated the task description. (Show Details)
nicolast added a project: Maniphest.
nicolast added a subscriber: nicolast.

Yes, this is definitely new behavior - looks like a regression. And a pretty bad one because it results in someone prioritizing something to the top of the list and not realizing but the task itself goes to the bottom of the queue. So basically, prioritizing via dragging is totally broken.

This is a pretty bad bug, IMHO, given that people are accidentally prioritizing stuff to the bottom when they think they prioritized to the top.

Just wanted to check in on this - it's a really bad regression that's affecting our entire company internally (in bad ways because top priorities are going to the bottom). So would appreciate any help on this regression!

T4778 covers how we prioritize, if you're curious.

@chad thanks - interesting that I don't see any mention of the word "regression" - as feedback, I find that if regressions (i.e. something used to work but now it doesn't) aren't prioritized, that means that we have to expect anything can break at any time (maybe we should stop auto-updating Phab altogether if this is the case :( ).

Please note that this bug fits in the category of "Bugs which are blocking users from getting work done." because it's causing us to literally lose work that was top priority for us, and for that to go unnoticed for days/weeks. People are putting items at the top of the priority list and they are literally going to the bottom without the user noticing. Think of it as an exploding time-bomb in that regard. It's subtle and I suspect that most users don't even know that it's happening to them, because you don't see it until you refresh it... but when they go in and find that all their tasks are out of order, they'll be really confused and upset.

Just my 2 cents...

I understand, but please note that we only have 1 developer working right now, and they are on security issues this week which always take priority. I am the designer, and I cannot address your bug other than to verify it. :-(

We prefer continuous release because it means we can address bugs, even regressions, faster than most other companies. We had a regression in Chrome, for example, that took 3 months to get pushed to stable.

Oh I didn't know you guys only had 1 dev :( good to know - I'll try to work with Nicolast to see if we can identify the source of the bug. Regardless of the issue we love your product <3!

Well we have 2 but 1 in getting drunk in Vegas for his birthday.

The behavior here was generally spooky and nondeterministic (see T5201, which had the same "spooky code" root cause), it just got even spookier recently. I think it should be more predictable after D12121.

This should be fixed in HEAD. I've pushed the change to this server if you want to try to catch any remaining issues before upgrading (we don't really use subpriority on this install, so don't worry about messing things up).


I can confirm this issue is fixed now. Thanks guys!