Windows on Wide screen have height higher than normal and resets position on restore

Issues - Platform and API
1

OverwolfLogs_2021-01-11_08-43-30.zip (1.2 MB)

Related app/team name (not a must if you want to keep it private): Trucky
Issue Description:

I’ve finally understood why this happen and I think it’s related to wide screens.

In-Game Windows have the height way too big than normal. The GameInfoVertical has size in manifest of 600 in height and on the user’s pc is 1200px (got from developer tools enabled on the user’s machine).

Also others windows have height way bigger than norma and they are default, not resized manually.

so, the user drag it in a visible area but the window actually has so big height (but invisible because the is transparent or opacity is 0) and at restore it resets to y = 0 or move a little bit to the top respect is previous position.

I’ve passed 40 minutes connected to the end user’s pc in TeamViewer to understand this.

hope this helps to understand better what’s going on and to help me to find a workaround.

Reproducted here:

And attached Overwolf logs.

Please try to fix this, a lot of users (and some popular streamer too) have this problems and they deal with it daily.

Can you reproduce it (exact steps to reproduce):
Reproducible on wide screens

Impact for my app: [e.g. x% of the users complained about it, it’s a show-stopper]: High
Do you currently have a workaround?
No

Please reproduce and attach a zip package of your OW client logs

2

HI.

We need to see how to test it with a wide screen… I will update.

Thanks.

4

So my analysis was correct?
It’s the strange or big height the problem?

5

I’m reiceving some reports more for this issue.
It seems users with a normal behaviour, suddenly have their overlays change position on game start.

Could be an issue introduced with 162.9?

6

@dowmeister

  1. do you know what the user screen size on the above video is?
  2. to clarify - your issue is that the in-game window not saves in the last position?
7

It’s the primary screen, i guess. it’s the wide screen with 1200px height.

I dont know if the in-game window not save the last position. We only know that windows keeps resetting. I think it saves it but is resetted at next restore.

User drag the window in a certain position.
ALT+G (for example) so hide and restore the window
The window resets

What i’ve seen using developer tools is the window was 1200px height while the normal size is 800px but most part of the window is transparent so anyone knows the real size without inspecting. Other users is reporting the same thing.
Going a bit deep, the window resets its position on the vertical axis:
User drag to 200, 100. Resets at 200, 0 (in this specific case when the window have height = screen height)

8

Yesterday i worked with testers trying to reproduce and find a sense to this problem.
At the end, i’m able to replicate to more computers, it’s not related to wide screens but to windows height.

I’ve distributed a version with red borders to highlight the windows real size.

From a tester:

image
image1920×1079 586 KB

Mine

image
image1920×1080 554 KB

Mine seems correct, is the manifest dimension, 800px height but the one from the tester is not, too high to be 800px.

So basically, reproducing it the behaviour is the following: windows have transparent space, the user drag it at the edge of the screen, the transparent part goes over the screen, when the window is restored it’s automatically reset to be contained completely inside the screen.

I’ve fixed this “bug” yesterday night but honestly, i dont like it: forcing the window to resize when the content change to fit the content adding +20px bottom to prevent window resizing when content change with little step. In this way the window height the user “guess” is the same as the real one. But i dont know if there are performances impacts if the window resize too many time.
So the user has

9

Maybe this https://overwolf.github.io/docs/api/manifest-json#restrict_to_game_bounds could fix the way users drag the window to avoid going over the screen edge?

10

Not sure if that will help. Worth a try, though. Not sure how it behaves on windowed mode.

11

The issue is not only on windowed mode but also on full screen.

I would to know thoughts on my analysis…

12

try this flag, it should work
keep_window_location

https://overwolf.github.io/docs/api/manifest-json#windows-keep_window_location

13

Already have.

"GameInfoVertical": {
    "file": "build/index.html",
    "keep_window_location": true,
    "transparent": true,
    "show_in_taskbar": false,
    "in_game_only": true,
    "override_on_update": true,
    "size": {
      "width": 250,
      "height": 800
    }
  },
14

Can you give us a version of the OPK with this window opens in every game? Can we quickly check it without installing ETS?

It’s not clear to me what is this height change.

15

No, unfortunately i can’t, the app works with the Telemetry Plugin and show data from the game so it’s not compatibile with any other game.

What’s not clear yet?

I’ve tried to explain with graphical example, highlighting window borders, reproducing the issue on multiple pc and screens… don’t know what i’ve to do to explain it better…

Basically, it’s a problem the window cannot be dragged OVER the screen edge because on restore resets its position.

I need the window stay where user has dragged it regardless the fact it’s over the screen \ game window edges.

16

@dowmeister Soon, I will finish downloading the game (hopefully…), and I will test it better.

17

Any change to managed reproducing the issue?

18

Hi @dowmeister,

So I installed your latest version (v2.2.28) and tested it, and I didn’t notice any heights issue. I opened the dev tools to see the windows border, and it looks fine.

I also got to the office today to check on our ultra wide screen to make sure it acts the same:

IMG_20210117_111648
IMG_20210117_1116484000×3000 871 KB

And again - I didn’t notice any issue with the heights… I understand the frustration, and I know that the problem exists. Maybe it’s related to the fact that I’m not familiar with the game or your app enough.

So - to make some progress - can we do a screen share session, so you can show it live on your machine?

Thanks.

19

The 2.2.28 contains a fix to mitigate this issue.
It resizes the window to the nearest height dimension to be sure the window is exactly what the user see.
But it’s a bit tricky because it fires a resize every time the content change and as that window is subjected to Real Time Telemetry events it receives a lot of data multiple time per second and actually i dont know if this is performance problem.

The executed code is

var contentHeight = $('main').outerHeight() + 20;
var windowHeight = window.innerHeight;

if (contentHeight != windowHeight) {
  overwolf.windows.getCurrentWindow(currentWindow => {
    overwolf.windows.changeSize({ window_id: currentWindow.window.id, width: currentWindow.window.width, height: contentHeight, auto_dpi_resize: false }, () => { });
  });
}

and it’s executed every time React fire “componentDidUpdate”. Adding the tolerance of 20px at the bottom i can ensure it’s not resized so often but it might happen.

Btw to reproduce it exactly, you have to switch to Game Info in Vertical mode. Also on Main window vertical mode, the issue can be reproduced. Modifying live the body border (1px solid red), you can get easily how big the window is.

If you use the production version now live, you can reproduce the issue because the window doesnt resize automatically

20

@dowmeister Got your response. I will check now with the live version and update you ASAP.

Thanks.

21

@dowmeister We finally reproduced it, and I’m going to open a bug for the R&D to check the root cause of the issue. ETA is the next iteration (1-2 weeks).

Sorry for the hassle, and thank you for your patience.

@itayG @avner-solomon @Icywave25 FYI

1 Like