Tabset is merged to the left on resize

[geusebi]

A tabset is merged on the left whenever I try to resize it horizontally, BUT it's happening only on non-primary displays.

Behaviour first seen on:
Light Table version 0.8.0-alpha
Binary version 0.31.1

Wasn't happening on:
Light Table version 0.7.2
Binary version 0.8.6

Three-headed display with primary display located on the left
OS: Linux 4.2.0-1-amd64 SMP Debian stretch 4.2.5-1 (2015-10-27) x86_64 GNU/Linux
Graphics card: GeForce GTX 750 Ti
NVIDIA Driver Version: 340.93

Example image

[geusebi]

If it can help I've noticed this (best explained with an animation):

Apparently the distance between the left margin of the window and the left margin of display is erroneously added to the expected position; and on overflow the tabsets are merged.

[Trapets]

Also on Win7 Pro (64 bit), LT v 0.7.2 (binary v 0.11.1-pre).

[kenny-evitt]

I was able to reproduce this just now with a recent source build (more recent than 0.8.0-alpha) on a Windows 7 computer.

I was able to confirm, via lt.objs.console.log calls, that the MouseEvent object being passed to the reaction function for the behavior ::set-width-final! in src/lt/objs/tabs.cljs has a clientX property that's greater than the same property for the supplied MouseEvent object passed to the reaction function for the behavior ::width!.

Here are the relevant MouseEvent properties, logged via (.log js/console e). The final event of the ::width! behavior reaction function:

altKey: false
bubbles: true
button: 0
buttons: 1
cancelBubble: false
cancelable: true
charCode: 0
clientX: 871
clientY: 374
ctrlKey: false
currentTarget: null
dataTransfer: DataTransfer
defaultPrevented: false
detail: 0
eventPhase: 0
fromElement: null
keyCode: 0
layerX: 8
layerY: 344
metaKey: false
movementX: 0
movementY: 0
offsetX: 9
offsetY: 364
pageX: 871
pageY: 374
path: Array[10]
relatedTarget: null
returnValue: true
screenX: 1189
screenY: 456
shiftKey: false
srcElement: div.vertical-grip
target: div.vertical-grip
timeStamp: 1447716696140
toElement: div.vertical-grip
type: "drag"
view: Window
webkitMovementX: 0
webkitMovementY: 0
which: 1
x: 871
y: 374
__proto__: MouseEvent

The event for the ::set-width-final! behavior reaction function call:

altKey: false
bubbles: true
button: 0
buttons: 0
cancelBubble: false
cancelable: true
charCode: 0
clientX: 1189
clientY: 436
ctrlKey: false
currentTarget: null
dataTransfer: DataTransfer
defaultPrevented: false
detail: 0
eventPhase: 0
fromElement: null
keyCode: 0
layerX: 326
layerY: 406
metaKey: false
movementX: 0
movementY: 0
offsetX: 327
offsetY: 426
pageX: 1189
pageY: 436
path: Array[10]
relatedTarget: null
returnValue: true
screenX: 1189
screenY: 456
shiftKey: false
srcElement: div.vertical-grip
target: div.vertical-grip
timeStamp: 1447716696242
toElement: div.vertical-grip
type: "dragend"
view: Window
webkitMovementX: 0
webkitMovementY: 0
which: 1
x: 1189
y: 436
__proto__: MouseEvent

[UnclassedPenguin]

I am also currently affected by this. Exact issue. Only on my secondary monitor.
Ubuntu 14.04
Light Table 0.8.0-alpha
Binary Version 0.31.1

[kenny-evitt]

@tvanden Only on your secondary monitor? That's surprising. What's the monitor/display configuration you're using? If the screen coordinates aren't even consistent between or among multiple monitors, I'm not sure how we can fix this.

[UnclassedPenguin]

@kenny-evitt
Not sure what monitor/display configuration it is? Or how to check that. it is a default ubuntu 14.04 install. Just using the display manager they provide.

[carocad]

Hello,
I can confirm that I'm also having this issue. My configuration is exactly that of of @tvanden:
Ubuntu 14.04
Lighttable 0.8.0-alpha
Binary version: 0.31.1

And as he mentioned it also happens only if I plug-in a secondary screen. If there is only one screen then the resizing happens without a problem. Also this behavior is new, as with the 0.7.x version that I had before this was never an issue.
My screen sizes are 14 inch (primary/laptop) and 19 inch (secondary screen)

PS: I just re-tested the behaviour and found out that it only happens if Lighttable is on my primary screen (laptop), but if I put it on the secondary screen then it the resize happens correctly (no bug). Thus I guess that Lighttable is somehow taking the biggest screen size and deciding if it should close the tabset when there is a resize.

Hope it helps

[Trapets]

Windows 7 Pro 64bit, LightTable v 0.8.0, single monitor. LightTable starts fullscreen mode (workspace tree open), opening 2 or more tabsets. After going to windowed-resized mode and by changing the size of the tabset the tabset-border jumps always to left or the tabsets are merged together.
Same behavior on Manjaro linux KDE, LightTable 0.8.0-alpha, single monitor.

I don't get this behavior on both os's if the left edge of LightTable window snaps to desktop edge.

[kenny-evitt]

Everyone, please download the (non-alpha) 0.8.0 release version and confirm whether you can reproduce this with that version. We upgraded the main framework LT uses – Electron – and the new version fixed other graphics issues.

[UnclassedPenguin]

@kenny-evitt
Hey, sorry to disappoint. on version 0.8.0 binary 0.34.5 I am still having this issue. On my primary screen (farthest left, if anyone else is noticing that) everything seems to be working fine. My two other monitors to the right of it still collapse on resize.

[kenny-evitt]

@tvanden Thanks for testing.

[carocad]

I can also confirm that the bug is still present on the 0.8.0 version.

[geusebi]

What actually is the purpose of set-width-final! in lt/objs/tabs.cljs?
I am asking this because it looks like removing it entirely fixed the bug. I don't know clojure enough to be sure of what I'm doing so I'll not send a pull request for now.

[kenny-evitt]

@geusebi My guess is that it's supposed to perform the final adjustment after you stop dragging the tabset. If it seems like removing it fixes this bug, create a PR and I'll test it out too. If it doesn't seem to break anything else, we can ask others to review the change as well. You're certainly not really any less of an expert about this code than I!

[geusebi]

Sorry, totally forgot to create the pull request.
If you can test it, I would appreciate it.