On re-focus of the Frame window, it forces itself to floating and snaps to right-side of screen in i3-gaps

[sk33z3r]

System Info:

• Frame: 0.5.0-beta.18
• NixOS 21.11
• i3 version 4.20 (2021-10-19)

Repro:

1. Open frame OBSERVE: By default the window is snapped to the right side of the screen, and "floating" in i3 terms (it can be dragged around the screen and not locked to a position)
2. Change window from floating to fixed, or drag the window somewhere else
3. De-focus the Frame window
4. Re-focus the Frame window

Expected: Frame window remains in the last position it was in, fixed or not

Actual: Frame always returns to floating, and snaps to the right side of the screen

Video:

https://user-images.githubusercontent.com/20587571/168160991-819d6124-196f-4f06-b728-a9c6b798902c.mp4

Relevant Logs:

[758914:0512/161343.817988:ERROR:frame_sink_video_capturer_impl.cc(296)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
[758914:0512/161343.818500:ERROR:frame_sink_video_capturer_impl.cc(296)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
[758914:0512/161343.818693:ERROR:frame_sink_video_capturer_impl.cc(296)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.

[goosewobbler]

@sk33z3r I suspect this is related to the Glide feature being enabled - this summons frame when you move the mouse to the right edge of the screen. Does it produce the expected behaviour when turned off?

[honkler]

Having the same issue in i3-gaps. Window goes floating on mouseover, weird graphical glitches and it'll either disappear entirely (0x0 resolution as in OP) or mess up half the workspace. Glide disabled/enabled makes no change, it still tries to float to the right edge of the screen (often the wrong screen too). If I force floating disable in i3 config it'll still go floating by itself on re-enter.

Makes the app unusable. Needs a way to entirely prevent floating.

[goosewobbler]

@honkler we have made some windowing changes (and will have more in the next build) in our Canary pre-release version - ask in our discord if you are interested in trying it out, would be interesting to get feedback.

[honkler]

I'm running this version now and it is much better. Amazing work! Couple things I'm noticing (glide/autohide both off):

• If I bring the window up with the shortcut/tray icon it will be in tiling mode for one frame before going floating, which is glitchy.
• When set to tiling manually, it will go floating when the mouse re-enters the window. This is really the main issue left. It would have to stay tiling at all times.
• On startup both windows are tiling. First mouseover the 'tray' window turns it into floating: [673096:1124/163212.394664:ERROR:frame_sink_video_capturer_impl.cc(370)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
• At any time entering the 'tray' window: [673039:1124/163314.468877:ERROR:browser_main_loop.cc(270)] Gtk: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed
• The floating 'tray' window can overlap the tiling 'dash' window, hiding its close button, which can lead to the following: mod+q'ing the 'dash' window:

  16:25:44.681 › Error: A window with id "dash" does not exist (windows.send)
  at send (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:394:38)
  at /home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:398:40
  at Array.forEach (<anonymous>)
  at broadcast (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:398:26)
  at /home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:406:13
  at Array.forEach (<anonymous>)
  at /home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:405:24
  at Array.forEach (<anonymous>)
  at Object.346ba9b6-7b06-4696-b3a4-c22ce8f9fd82 (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:404:13)
  at /home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:119:71
  at Array.forEach (<anonymous>)
  at notify (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:119:36)
  at Timeout._onTimeout (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:173:67)
  at listOnTimeout (node:internal/timers:559:17)
  at process.processTimers (node:internal/timers:502:7)

  Trying to then reopen the 'dash' window through the button in the 'tray' crashes the app

  16:26:32.112 › Uncaught Exception! TypeError: Object has been destroyed
  at Dash.hide (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:312:42)
  at Object.hideDash (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:421:14)
  at Object.<anonymous> (/home/a/bin/frame-dist/resources/app.asar/compiled/main/index.js:309:31)
  at observe (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:91:26)
  at process (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:109:7)
  at notify (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:120:5)
  at Timeout._onTimeout (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:173:67)
  at listOnTimeout (node:internal/timers:559:17)
  at process.processTimers (node:internal/timers:502:7)
  16:27:00.901 › Application closing
  16:27:00.903 › closing worker controller

  -mod q'ing the 'tray' window keeps the tray icon alive, summoning it then results in:

  16:42:28.214 › Uncaught Exception! TypeError: Cannot read properties of undefined (reading 'focus')
  at Object.focusTray (/home/a/bin/frame-dist/resources/app.asar/compiled/main/windows/index.js:424:22)
  at Object.<anonymous> (/home/a/bin/frame-dist/resources/app.asar/compiled/main/index.js:310:31)
  at observe (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:91:26)
  at process (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:109:7)
  at notify (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:120:5)
  at Timeout._onTimeout (/home/a/bin/frame-dist/resources/app.asar/node_modules/react-restore/lib/index.js:173:67)
  at listOnTimeout (node:internal/timers:559:17)
  at process.processTimers (node:internal/timers:502:7)
  16:42:35.082 › Application closing
  16:42:35.085 › closing worker controller

  The expected mod+q behavior imo would be kill the window until it is the last window left at which point kill the process. Hope this helps, I'll let you know when I notice anything else.

[goosewobbler]

@honkler Thanks for the detailed feedback! We'll try to look into this before the public release.

[goodvin]

I have the same issue - when the mouse pointer leaves the window it switches it back to floating.

[DPTJKKVH]

Hey everyone. In case someone is as frustrated as me with the Frame window always snapping to the right: I have "fixed it", though in a very crude way because I'm a noob. You can find more details and the code diff here: https://github.com/floating/frame/issues/1453#issuecomment-1459054883

Even a noob can see from the diff that I didn't add any malicious code. So if you are desperate for a fix, you can just download my repo and compile the code. I will merge upstream changes until the Frame team properly fixes this bug.

[goosewobbler]

Hi @DPTJKKVH, thanks for the attempt at fixing this. The windowing management is very sensitive so we will need to test any changes in this area thoroughly across all the platforms we support. If you want us to take a look at this code with a view to integrating it you could submit a PR with your changes, you will need to remove the commented out code.

[DPTJKKVH]

Hi @goosewobbler, thanks for reaching out. This is just a small hack/workaround for people who need this fixed asap.

I can somewhat read and manipulate existing JavaScript/TypeScript but that's it. I couldn't even write you a working hello world from scratch. I could brute force myself towards the exact combination necessary to stop the (main) Frame window from snapping to the right on re-focus. It's either glide and/or some forced window position. Though you would have to actually fix the bug, as in not breaking feature A to fix bug B.

Please forgive my ignorance if this is a preposterous proposition. I mean no disrespect. I'm simply a noob trying to help. I'm fine with maintaining my dirty little fork for the foreseeable future, if necessary.

[goosewobbler]

Ok @DPTJKKVH, thanks for clarifying - I would say that the current right hand side docking of Frame isn't a bug but a conscious decision to limit the options available whilst we work on a more complex set of options around windowing behaviour. The issues this docking restriction has with i3-gaps and other windowing managers are simply a consequence of this intentional limitation. We are going to address this soon with the ability to switch between left / right docking and a free-floating window. The former should be relatively easy to implement, the latter has a lot of different edge cases and surrounding considerations so may take a bit longer.