A little while back, I made a single comment that “Unity doesn’t care” on an aging thread that got no attention. Then suddenly there were 4 Unity employees that cared. I am calling on them to keep caring by explaining why confirmed bug reports simply get closed as “Won’t Fix” so often.
I realize this bug is not in the 2D category, and maybe it’s not your job. But can you see why it’s so easy to feel like Unity doesn’t care when confirmed bugs are simply marked as “Won’t Fix” with no reasoning given? Maybe you can talk to someone over there in that department? Maybe you can make a difference in Unity as a whole instead of just in 2D. We developers need allies within Unity, instead of feeling like we’re always fighting against it.
The bug is this… When you have multiple “Project” tabs open and they’re all locked to different parts of the Assets list, if you maximize any tab then un-maximize it, suddenly all of the locked Project tabs are locked to the same part of the Assets list (it seems to choose one at random to use for all the tabs).
It’s infuriating when you’re trying to work with assets in different parts of your project and not lose your spot. It seems like it should be an easy fix, yet they deemed it unworthy because it doesn’t affect I lot of people, I guess.
Its probably because the Project window is very old and rooted in IMGUI, and there’s probably a new UI Toolkit one on the horizon (like how there’s a new UI Toolkit hierarchy window).
So Unity’s time is better spent simply working on the newer solution than trying to maintain the old one.
If this is the case, and a new version of the editor UI is imminent, I would much rather have them tell me “that will be fixed in the new version of the editor UI, which we’re working on”. Simply “won’t fix” is extremely annoying, especially with how often it happens.
All they have to do is keep the bug report open as confirmed. Then when they put out the new version that non longer contains this bug (assumingly because the new version wouldn’t have the bug in the first place), then they close it as fixed. Project management is hard.
You in the alternate timeline where the bug report is left open for ages: “Unity doesn’t care. They confirmed my bug but haven’t done anything with it for months.”
Yes, as you already stated, this was not handled by the 2D team or anyone you tagged into this thread so asking the 2D team for an explanation on a case that is way outside our area isn’t something we can do. All we can do is point your post to the QA/team in question but that’s all.
I can see you’ve already reached out on the bug case itself so I do hope that the team or QA can elaborate for you.
We were discussing this on our 2D team chat in the last few minutes and interestingly I was made aware of some issues with Jira not posting the resolution notes in a whole bunch of recent cases (we’ve had a new Jira workflow implemented over Xmas) so it might be related to that automation issue, not sure.
Your issue seems to have the default response if it’s left blank and I understand how that canned response can be frustrating!
Hi! I’m the person who closed the ticket you linked. First, I notice that you are not seeing resolution notes on your ticket, which looks like a bug in our system. As Melvin mentioned, we have transitioned recently and some issues are bound to arise. Rest assured that we can’t close a ticket without resolution notes.
That said, I did put in the “generic” won’t fix message:
Thank you for reporting a bug to Unity.
We have reviewed the issue carefully, and in this case, the team is unable to prioritize fixing this bug. There are a number of reasons we make this decision, including the impact and severity of the issue across our user and customer base, and the possibility that future plans may solve the problem in a different way, or that a workaround for the bug may be available.
Today we will be closing this case. Thank you again for taking the time to report this issue, and please let us know if there is anything else that changes the impact or severity of this issue.
I feel like it generally captures the reasoning for closing most bugs without going into too much needless details. It applies to the bug you reported as well, but I can elaborate a tiny bit: some systems like the Project Browser and the Windowing system are very sensitive to changes while being extremely core to the user experience. It is very hard to justify the time and, to a greater extent, the risk of introducing regressions that come with fixing a bug in those areas unless it’s quite severe. This is a conscious choice we are making to maintain stability.
As for the close vs keep open question: we decided that it was better to be honest about our capacity and intent to fix bugs. We believe it is better to let you know as early as possible that an issue will not be addressed.
Hopefully, this lessens the frustration a bit. I know it’s still frustrating, though. It is for us as well, believe me!
This is exactly why it should be fixed. You have a known bug in the core user experience and have chosen not to fix it. From my perspective, this should be an easy fix. Find where the Project views are refreshed and fix the reason why it’s not restoring the last known view. If the Project Browser window is that sensitive to simple changes, then I fear for the quality of engineering behind it.
And yet, it is not. I know exactly why this is happening and I promise you the fix is too risky for the severity of the symptoms. This is based on the fundamental design of the windowing system, specifically maximization and minimization. It’s also related to the docking system and the global selection. It’s unrelated to the Project Browser itself.
Can you elaborate on what this issue is preventing you from doing? I must admit I have a hard time understanding what the local selection in locked Project Browsers that are part of the same tab group is useful for. If I understood better, we could either review the severity of the issue or we could come up with alternative workflows.
the missing resolution notes appear to be a system issue, as tickets cannot be closed without them and recent transitions have caused some glitches. The generic “won’t fix” message applies here because core systems like the Project Browser and Windowing are highly sensitive, and fixing non-critical issues there carries a high risk of regressions. We chose to close the ticket early to be transparent about our capacity and intent, even though we understand this is frustrating for you and for us as well.
The original bug report included a video that demonstrated what I was doing and why it was breaking the workflow. However, I can go into it again here.
First I’d like to say that I am not a hobbyist developer. I am independent, but I work on large projects. This issue is mostly a problem for large projects. I realize that probably a majority of Unity users are hobbyists or small-project independents.
Large projects have lots of assets. Organization of assets within large projects is critical. Well-organized folder structures with multiple levels of hierarchy is very common to keep assets organized.
It’s a normal part of the Unity workflow to link assets to inspector properties. Sometimes you need to have multiple Project tabs open and locked when you are linking lots of assets to lots of other inspector properties. If you don’t lock them, you lose your spot as soon as something else is clicked. The locking mechanism is critical for workflow, and I’m glad it exists. But it goes out the window as soon as it stops working as expected. The more locked Project tabs you’re working with, the more frustrating it is when they all change to something they weren’t locked to.
I’m not sure what you mean by “same tab group”. I have tested this bug using multiple Project tabs that are all in different groups, and it still happens.
A preferable solution would be for Unity to allow opening a Project tab with a specific folder as the root of it, which only showed the contents of the folder. I’ve seen this requested by at least one other user in the past. But we have the locking feature, so theoretically we don’t need a new feature, we just need the existing feature to work as intended. As a software engineer myself, it just blows my mind that anyone would think it’s better to have a known bug than to fix it. And if the fix for something this simple is too risky, then there’s a bigger underlying problem with the engineering behind the entire Unity UI. That should be prioritized.
If you ask me what the biggest problem with Unity is, I would immediately say the errors in the editor. The engine itself is generally decent. But the experience working in the editor is bad. I’ve been using Unity since 2010, so I know what errors and warnings to ignore and how to work around things. But what about developers new to Unity? If it was my first experience with Unity and saw all those errors and warnings, and the editor was just buggy, I would find a different tool to use. To me, that’s why Unity will fail… not due to any lack of next-gen features in the engine.
It’s not the same group, but here’s another demo video that shows how multiple locked Project tabs is useful, and how disruptive it is for them to reset unexpectedly. It doesn’t mention in this particular video, but running the game with “Maximize” will also cause the problem.
Thank you, it is much clearer now what the issue actually is.
From the bug report, this is what confused me:
Actual result: All Project tabs have the same asset selected
Expected result: All Project tabs have selected their previously selected assets
…
Notes:
Not reproducible if the Project tabs are on different panels
From this, I concluded that you cared about the internal selection of each panel. But from this new video, it is abundantly clear that this is not what you meant and that it is, in fact, reproducible when the tabs are on different panels.
This is making a much more compelling case to attempt a fix. I have been a 2-locked-Project-windows-guy myself since ~2012 so I get it (never been a user of the One Column mode, however).
I will re-open the bug with a more accurate formulation and link your YouTube video for reference. Out of transparency though, the priority remains low and as such we may never get to it.
it just blows my mind that anyone would think it’s better to have a known bug than to fix it
As you noted yourself: we don’t have a known bug, we have hundreds. It is physically impossible to get to all of them; and with the number of users and workflows we support, it’s all about maximizing the return on investment and minimizing risk for everything we decide to fix. I said it before and I’ll say it again: it breaks our hearts to have to do this.
This is the result of someone at Unity rewriting my bug report wording. This seems to happen all the time. I didn’t word it that way… I never said anything about “same tab group” in the bug report that I submitted. I have a feeling that whoever “confirms” the bug tries to reword it so the Unity engineers will better understand it, which I can understand, but a lot of the time the rewording gets lost in translation. I submitted a link to a similar video with the original bug report. Not sure if those get looked at.
The bug is this… When you have multiple “Project” tabs open and they’re all locked to different parts of the Assets list, if you maximize any tab then un-maximize it, suddenly all of the locked Project tabs are locked to the same part of the Assets list (it seems to choose one at random to use for all the tabs).
It’s infuriating when you’re trying to work with assets in different parts of your project and not lose your spot. It seems like it should be an easy fix, yet they deemed it unworthy because it doesn’t affect I lot of people, I guess.
hmm years ago I tried to go with 2 project window panels many years ago, both with different view layouts ie 1 column layout on a sidebar, and larger one with the classic 2 column layout.. wanting to have them work independently in order to work between folders and not lose folder locations , to avoid crap worfklow of trying to get back to the previous location etc… I gave up.. due to the way the project window works with everything else you can’t just specify this is main project window Do not let anything else mess with any other project windows I have opened at specific folder locations etc. The project window is long overdue an overhaul and unlike the hierarchy which has seen more third party improvement over the years not so much for the project window.
I do think Unity just simply don’t understand improving workflow ux, in the way they’ve made settings and menus, infact the last 5 years would suggest anti workflow and anti time saving
