mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-26 01:06:00 +03:00
[GH-ISSUE #1329] Freeze of application when trying to enter query arguments in WebSocket URL #434
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#434
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @levrik on GitHub (Nov 15, 2020).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/1329
Describe the bug
Typing
?or=in WebSocket URLs cause freezes or let the whole application hang.To Reproduce
Type a long URL as WebSocket URL. For example
ws://localhost:8000/ws/2f2dffb6-55e0-49b4-a879-8d2470dbed12.Now add a
?to the end, you'll experience a freeze. Type a query argument name and try to enter=.You'll experience a freeze again. I didn't wait this time since it didn't resolve after over a minute.
Expected behavior
To don't freeze.
GIFs
On the last freeze at the end of the GIF I was trying to insert
=.Desktop (please complete the following information):
Additional context
This doesn't happen on shorter URLs. For example no way to reproduce with the example URL
wss://echo.websocket.orgby just trying to add a query parameter here.But can also be reproduced by just adding some more characters as path. The longer the whole URL gets, the worse the freeze on entering
?or=.Also happens in
Socket.IOtab, doesn't happen for SSE and MQTT.Also not for other top-level tabs outside of
Realtime.@levrik commented on GitHub (Nov 18, 2020):
@liyasthomas Wondering why this is considered minor since I always have to pre-type the URL somewhere else and copy it to Hoppscotch now. And if you forget about this, completely freezing, going to Task Manager and killing the process, restarting, putting URL in again. This costs a lot of time.
@hariaakash commented on GitHub (Nov 26, 2020):
This is an issue with the Regex test-taking more time to complete especially with special characters and hanging the tab. There are two ways to solve this IMO. Probably debounce can help the user enter the URL completely. Or when the user clicks on submit then test and throw error.
@connorwang commented on GitHub (Nov 30, 2020):
We're having same issue.
@AndrewBastin commented on GitHub (Nov 30, 2020):
Yeah. As @hariaakash pointed out, a good solution for this would be to debounce the check. But it may still freeze out. So I was thinking of a way to run tests asynchronously or atleast in a non-blocking way so the UI doesn't freeze up during the test (web worker ? custom logic which splits test work to smaller tasks ran during free time ? etc.)
But I think debouncing would be a good start. If anyone wants to pick it up, please feel free. Else I will get it done in the coming days.
@hariaakash commented on GitHub (Nov 30, 2020):
I have fixed this, will make a PR @AndrewBastin
@levrik commented on GitHub (Nov 30, 2020):
@AndrewBastin I'm a bit confused why the regex is required at all in this tab. Other tabs don't hang on the same URL so it seems that they don't run this regex. What's the difference between the tabs?
@liyasthomas commented on GitHub (Nov 30, 2020):
Regex is basically used in all tabs/pages to validate the input URL. In the case of WebSocket, it validates URL for ws/wss protocols.
@levrik commented on GitHub (Nov 30, 2020):
@liyasthomas I see but I don't really get why it is slowing down so much. Shouldn't checking for
ws://orwss://at the beginning of the string be enough in this case?I'm guessing that it shouldn't be too bad to test for a valid URL in general as well on top of this, so regex doesn't seem wrong as well but for other parts of the app, this freeze doesn't happen so I'm wondering what the difference here is between the regex patterns.
I didn't look at the code here so I'm just randomly guessing.
@liyasthomas commented on GitHub (Dec 1, 2020):
@levrik can you confirm this deploy preview solves this issue.
Deploy preview: https://deploy-preview-1354--hoppscotch.netlify.app/realtime
cc: @connorwang