inspector glitch, anyone?

Unity Engine
1

I’m getting this but QA can’t repro, does anyone else have that?

560×548 21.5 KB

2

I saw this once, but it was 2am and I was just trying some new features out in an empty project. Just deleted the project and went to bed. I recall clicking something in the inspector when it happened. I thought I had somehow accidentally ‘expanded’ the top part of the inspector.

3

found it: when you open the profiler and add gpu, the inspector gets stretched

4

Sounds like someone is modifying a style, rather than a copy of the style, in there.

5

Did you tell QA? Could you post the case #?

6

yeah i looks like that doesn’t it, but it’s doing it even on a brand new project so unless styles persist across new launch of the editor that’s ruled out
qa knows, can’t repro, case# is 989953

7

By someone I mean Unity. Not the first time it’s happened, if that’s the case. :stuck_out_tongue:

8

I’ve got a repro, the tricky part was that the bottom view in Profiler needed to be in Hierachy view with a Details View on the right hand side (not open by default but state saved to Editor Prefs, which is probably why you missed it in the repro steps and QA missed it when trying to repro). GPU or CPU doesn’t matter. Oh yeah, and you also need to be profiling or have some profiled frames loaded, otherwise, Hierachy is showing nothing.

I’ll fix it asap, thanks for reporting :slight_smile:

3 Likes
9

gg

10

Fixed it, it might be a while until it goes through all the motions and lands in a beta release down the road, though.

11

why a while? battery of tests?

12

yes, every change needs to first pass a series of reviews and tests before it gets merged into the main line (trunk) and then again for a backport into an already branched off beta cycle like in this case. We’re taking the potential for regressions serious and we also don’t want bugs fixed in the beta and suddenly reappear in trunk so that’s why it’s this slightly staggered process :slight_smile:

1 Like
13

how are gui bugs auto tested?

14

Well, in this case the change is very contained and will not really get tested, but the changeset still needs to go through our entire test framework to verify that didn’t break anything. There are tests that might fail if the fix would contain more involved changes e.g. somewhere deep in IMGui Code. Also, there are UI automation frameworks that would simulate button presses and can read window contents, but they aren’t used here.

So yeah, the testing for this fix is mostly there to uphold the process so I can’t just claim: here’s a fix, it wont break anything.

Also, QA will have to verify this fix before the relevant build would be released.

2 Likes
15

interesting, can you elaborate how this works?

16

We have some internal tooling for that and with that it looks somewhat like this:

using UnityEngine.TestTools;
using NUnit.Framework;
using UnityEditor;
using System.Linq;
using UnityEngine;

    [Test]
    public void CanClickOK()
    {
        InspectorWindow inspector = EditorWindow.GetWindow<InspectorWindow>();
        using (var automatedInspector = new UnityEditor.UIAutomation.AutomatedWindow<InspectorWindow>(inspector))
        {
            var okButton = automatedInspector.FindElementsByGUIContent(new GUIContent("OK")).First();
            Assert.NotNull(okButton);
            automatedInspector.Click(okButton);
        }
    }

There are some caveats and gotchas when using this like, if the element is not visible, it can’t be clicked. Since our build/test farm runs the windows unmaximised and at a low screen resolution, tests like that can be rather unstable if you’re not careful about the window setup. I think that’s one reason why it is not used too much, the other being that we’re exposing a lot of API so the need to go through a window to test functionality isn’t that huge and UI tests are pretty high level and therefore slower and more prone to breakage as we rearrange stuff.

A quick google search revealed this small package for ingame UI testing:

I glanced over it and it seems to offer some similar functionality.

1 Like
17

I see both UT and this ui tester use the button name or string compare to validate UI so they wouldn’t catch a layout bug like this one. Thanks for the info, it’s useful.

18

You’re right and testing layout would be a whole other mess I fear. I just had a discussion if we could ad some tests or safeguards for this specific case but it seems impractical at this point. But I’m glad I could shed some light on the testing process :slight_smile:

2 Likes