Problems with first startup since 46-beta(?): window is oddly sized at first, clicking on Updates is read as a click on the main ad banner

For the last few days, Fedora's openQA tests of GNOME Software on F40 and F41 have been behaving unreliably. It seems like GNOME Software's startup behaviour has changed in several ways.

Looking at the videos of failed tests, and reproducing locally in a VM, I see a couple of things. Firstly, it seems like at first, the window is slightly oddly sized. openQA tests at 1024x768, and at this resolution gnome-software usually runs in a full-size window (taking up the whole of the desktop, but not literally "full screen" in the sense of hiding window controls and stuff). But it seems like in these tests, it's loading in a slightly shorter (but still full-width) window at first, then resizing to full-size.

Secondly, openQA needs to click on the 'Updates' link (in the Explore / Installed / Updates row at the top of the window), and sometimes this is somehow read as a click on the big 'ad banner' below it, so the test winds up on the page for whatever app is being advertised instead of the "Updates" page, and fails. here is an example - I've restarted that test four times now and it's failed the same way every time (so five failures total). openQA is definitely clicking in the right place: at 18:40:00.259 in the video you can see the cursor briefly appear as it clicks. But it winds up on the Deja Dup page. I think possibly this problem only happens when openQA clicks while the 'shorty window' problem is in effect, indicating some kind of geometry weirdness is causing both problems, or something.

I've tried this in a local VM and I can see the 'shorty window' problem happen, but it only seems to happen very briefly. In openQA it seems like it must be happening for longer, because I set the test to wait for the screen to be still for at least five seconds after 'seeing' the Updates button before actually clicking on it, and these failures are still happening. In the case I linked, from the video timestamps, it seems the 'shorty window' state was active from 18:39:53 to 18:40:00 (the closest delta I can get is that we're still in shorty-window state at 18:40:00.760, which seems to be the frame the test clicks at, then we're in full-size state at 18:40:01.769). It's possible that openQA clicking actually somehow ends the shorty-window state, I guess. openQA doesn't really "move the mouse" like a human would, it more sort of 'teleports' the cursor; it uses VNC, and when it wants to click, it just sends a VNC click event at the co-ordinates it wants to click on, so the cursor doesn't really "move" like it would if a human was piloting a mouse.

I tested this in a local VM and I do see the 'shorty window' thing happen, but in that case it only ever seems to happen really briefly, not long enough for me to humanly manage to click "Updates" while the window is in that state. As noted above, in openQA failure cases it seems like the window is in that state for at least 7 seconds. Possibly the difference has something to do with openQA's robot-like pointer movement, I'm really not sure.