You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've observed this issue for a few years now back when I started to work with RAP-3.1 and it still is present in RAP-3.22. From time to time and for no appearant reason clients stop responding to browser-resize events, while everything else continues to work just fine.
Typically when resizing the browser window, the client accumulates changes and periodically pushes those values to the server (setBounds, notifyResize). At first I had doubts whether this could be an issue with application-code (some resize-listeners missing), but than I noticed even a minimal example with only an empty entrypoint causes those setbounds/notify-messages to be sent over.
For a client in degenerated state however, no network messages are sent to the server on resize - and while other events/etc work just fine, also other events don't cause a resize (so this rules out those resize-messages are just stuck somewhere and don't cause a flush).
I tried to debug the issue further, but now I am a bit stuck:
in _dispatchEvent (Internal event dispatch method), I see evt._valueType with "windowresize", so the browser seems to trigger the event:
and later recompute also detects the width changes:
after which it flushes the GlobalQueues. but no network request is issued by this.
In contrast, on a working client I get additional related events after a browser resize, like the changeWidth event shzown in the screenshot below. This changewidth-event is completly missing in the dysfunctional state:
I would be really grateful for hints where to debug / search further. The fact that this seems to happen seldom and quite random makes it hard to dig deeper...
Update: I wasn't sure whether this happens only on Firefox, but in a ticket from 2019 I just found the note "mostly happens when using google chrome". so the issue doesn't seem to be browser-specific.
The text was updated successfully, but these errors were encountered:
the code you are looking for is in Shell.js. The "windowresize" event is attached in "_applyMode" function when the mode is "maximized". Then in onWindowResize we send the bounds of the Shell to the server.
I hope that with these pointers you can debug what's the problem.
in broken state, _onWindowResize is not called - the sendBoundsTimer is inactive and all flags are false (sendmMve, sendResizeDelayed, sendResize). So maybe the listener hasn't been attached, I'll dig further...
I've observed this issue for a few years now back when I started to work with RAP-3.1 and it still is present in RAP-3.22. From time to time and for no appearant reason clients stop responding to browser-resize events, while everything else continues to work just fine.
Typically when resizing the browser window, the client accumulates changes and periodically pushes those values to the server (setBounds, notifyResize). At first I had doubts whether this could be an issue with application-code (some resize-listeners missing), but than I noticed even a minimal example with only an empty entrypoint causes those setbounds/notify-messages to be sent over.
For a client in degenerated state however, no network messages are sent to the server on resize - and while other events/etc work just fine, also other events don't cause a resize (so this rules out those resize-messages are just stuck somewhere and don't cause a flush).
I tried to debug the issue further, but now I am a bit stuck:
after which it flushes the GlobalQueues. but no network request is issued by this.
In contrast, on a working client I get additional related events after a browser resize, like the changeWidth event shzown in the screenshot below. This changewidth-event is completly missing in the dysfunctional state:
I would be really grateful for hints where to debug / search further. The fact that this seems to happen seldom and quite random makes it hard to dig deeper...
Update: I wasn't sure whether this happens only on Firefox, but in a ticket from 2019 I just found the note "mostly happens when using google chrome". so the issue doesn't seem to be browser-specific.
The text was updated successfully, but these errors were encountered: