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.

ahah nice! well-deserved :)

@epriestley, this bisects to D11922

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.

<3 <3 <3

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

Awesome!

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