starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #471] WebSocket page freezes when pasting long URL #183

New issue

Closed

opened 2026-03-16 13:55:13 +03:00 by kerem · 7 comments

kerem commented

2026-03-16 13:55:13 +03:00

Owner

Originally created by @igorrocha on GitHub (Jan 3, 2020).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/471

Describe the bug
When trying to paste a very long URL on the websockets page (https://postwoman.io/realtime/), the page freezes without any error message on the browser console.

To Reproduce

Go to https://postwoman.io/realtime/
Click on the URL field
Paste a long URL, such as wss://eyJraWQiOiJBMjhyeTdtRWhzTktWQTFDTms4YXlIcVBDVjdXVmxuWFwveFFZQWJLdU1qQT0iLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiZXFCeml1a2ZJOGxaNDlrTHB3Mk4xdyIsInN1YiI6ImYyZDY4MTFhLThhNDMtNDRhYi1iZTU4LWYxNTMyMGYwN2NjMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpc3MiOiJodHRwczpcL1wvY29nbml0by1pZHAudXMtZWFzdC0xLmFtYXpvbmF3cy5jb21cL3VzLWVhc3QtMV9wVjlwbWhacUIiLCJjb2duaXRvOnVzZXJuYW1lIjoiZjJkNjgxMWEtOGE0My00NGFiLWJlNTgtZjE1MzIwZjA3Y2MwIiwiYXVkIjoiMjlrb2xxYnRiY3RqOWE3dmJkOTllYzdnaHYiLCJjdXN0b206dGVybXMiOiJ0cnVlIiwiZXZlbnRfaWQiOiI3NjY3ZDdhZC0yZGYzLTQ1NjEtOTU0Mi1kNDVlM2NjZmQ0ZjEiLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTU3ODA2MDgwOSwibmFtZSI6IlRlYW0gMSBTZW5kZXIiLCJleHAiOjE1NzgwNjQ0MDksImlhdCadvdsvsvsvd3vjng9HsIEAFoxTJjpXCypUb5-N3cO-e3NSCVXZzvBqqsXJfWOpWaxrUpKdTnV00agEpoOPh8DpytM1EhZzThAXHxzOAb4eDRymaPbKnvW31SvjhbZR2mENExdeT9HtQlsrE7zWHsZ7Scbb0HsQlNIDZFb7B-2I3tU1SPcHkBZMOpyJlKIvMtDk24TCjD8RJpvb1-aV8k_2T9OKgFWbe213kecqFL7EfeHjimbN3l8FzoFEj-XvbcGI_cFnQa2fBptSiM7DS5GonxnlCwUe1ATbtIBFOHY8U-UWTw@echo.websocket.org
The browser tab freezes.

Expected behavior
The URL should be pasted normally, and I should be able to connect to it.

Desktop:
Tried on three environments:

OS: Manjaro ArchLinux
Browser: Chrome
Version: 79.0.3945.88 (Official Build) (64-bit)

OS: Manjaro ArchLinux
Browser: Firefox
Version: 71.0 (64-bit)

OS: Mac OS Catalina
Browser: Chrome
Version: 79

Additional context
One thing I noticed is that when the tab freezes there's a spike in CPU usage on the computer (I measured it on the system monitor, and also the laptop's vents went off like crazy). My guess would be that there's some sort of client side validation of the pasted URL, and such a long URL is too demanding of it. That's just a guess, however, as I couldn't find a way to debug it.

Originally created by @igorrocha on GitHub (Jan 3, 2020). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/471 **Describe the bug** When trying to paste a very long URL on the websockets page (https://postwoman.io/realtime/), the page freezes without any error message on the browser console. **To Reproduce** 1. Go to https://postwoman.io/realtime/ 2. Click on the URL field 3. Paste a long URL, such as wss://eyJraWQiOiJBMjhyeTdtRWhzTktWQTFDTms4YXlIcVBDVjdXVmxuWFwveFFZQWJLdU1qQT0iLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiZXFCeml1a2ZJOGxaNDlrTHB3Mk4xdyIsInN1YiI6ImYyZDY4MTFhLThhNDMtNDRhYi1iZTU4LWYxNTMyMGYwN2NjMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpc3MiOiJodHRwczpcL1wvY29nbml0by1pZHAudXMtZWFzdC0xLmFtYXpvbmF3cy5jb21cL3VzLWVhc3QtMV9wVjlwbWhacUIiLCJjb2duaXRvOnVzZXJuYW1lIjoiZjJkNjgxMWEtOGE0My00NGFiLWJlNTgtZjE1MzIwZjA3Y2MwIiwiYXVkIjoiMjlrb2xxYnRiY3RqOWE3dmJkOTllYzdnaHYiLCJjdXN0b206dGVybXMiOiJ0cnVlIiwiZXZlbnRfaWQiOiI3NjY3ZDdhZC0yZGYzLTQ1NjEtOTU0Mi1kNDVlM2NjZmQ0ZjEiLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTU3ODA2MDgwOSwibmFtZSI6IlRlYW0gMSBTZW5kZXIiLCJleHAiOjE1NzgwNjQ0MDksImlhdCadvdsvsvsvd3vjng9HsIEAFoxTJjpXCypUb5-N3cO-e3NSCVXZzvBqqsXJfWOpWaxrUpKdTnV00agEpoOPh8DpytM1EhZzThAXHxzOAb4eDRymaPbKnvW31SvjhbZR2mENExdeT9HtQlsrE7zWHsZ7Scbb0HsQlNIDZFb7B-2I3tU1SPcHkBZMOpyJlKIvMtDk24TCjD8RJpvb1-aV8k_2T9OKgFWbe213kecqFL7EfeHjimbN3l8FzoFEj-XvbcGI_cFnQa2fBptSiM7DS5GonxnlCwUe1ATbtIBFOHY8U-UWTw@echo.websocket.org 4. The browser tab freezes. **Expected behavior** The URL should be pasted normally, and I should be able to connect to it. **Desktop:** Tried on three environments: - OS: Manjaro ArchLinux - Browser: Chrome - Version: 79.0.3945.88 (Official Build) (64-bit) --------------- - OS: Manjaro ArchLinux - Browser: Firefox - Version: 71.0 (64-bit) --------------- - OS: Mac OS Catalina - Browser: Chrome - Version: 79 **Additional context** One thing I noticed is that when the tab freezes there's a spike in CPU usage on the computer (I measured it on the system monitor, and also the laptop's vents went off like crazy). My guess would be that there's some sort of client side validation of the pasted URL, and such a long URL is too demanding of it. That's just a guess, however, as I couldn't find a way to debug it.

kerem

2026-03-16 13:55:13 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-16 13:55:29 +03:00

Author

Owner

@igorrocha commented on GitHub (Jan 3, 2020):

Another bit of additional context: the reason for using such a long URL is that I'm trying to pass an Authorization header with the request. I'm trying to use the workaround suggested by @liyasthomas on #321

@igorrocha commented on GitHub (Jan 3, 2020): Another bit of additional context: the reason for using such a long URL is that I'm trying to pass an Authorization header with the request. I'm trying to use the workaround suggested by @liyasthomas on #321

kerem commented

2026-03-16 13:55:34 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jan 3, 2020):

Issue has been identified. I think there might be three reasons for this behaviour:

~~App's current state is saved to localStorage via Vuex. Long URL string might've crashed Vuex binding. Anyway, I'm not sure of whether this is the reason yet.~~
~~Browser specific bug: Chrome used to crash while pasting large strings into input boxes. Since behaviour is repeated on Firefox, this possibility can be excluded.~~
There's a client side validation for checking the WSS URL. This is implemented in regex. This might've caused CPU race condition based on given pattern checking. This is a highly possible reason

Anyway, stay tight, will fix ASAP.

Found the issue: it was #3

@liyasthomas commented on GitHub (Jan 3, 2020): Issue has been identified. I think there might be three reasons for this behaviour: 1. ~App's current state is saved to localStorage via Vuex. Long URL string might've crashed Vuex binding. Anyway, I'm not sure of whether this is the reason yet.~ 2. ~Browser specific bug: Chrome used to crash while pasting large strings into input boxes. Since behaviour is repeated on Firefox, this possibility can be excluded.~ 3. There's a client side validation for checking the WSS URL. This is implemented in regex. This might've caused CPU race condition based on given pattern checking. This is a highly possible reason Anyway, stay tight, will fix ASAP. Found the issue: it was `#3`

kerem commented

2026-03-16 13:55:39 +03:00

Author

Owner

@igorrocha commented on GitHub (Jan 3, 2020):

That was super fast, @liyasthomas , thank you very much!

@igorrocha commented on GitHub (Jan 3, 2020): That was super fast, @liyasthomas , thank you very much!

kerem commented

2026-03-16 13:55:44 +03:00

Author

Owner

@igorrocha commented on GitHub (Jan 6, 2020):

@liyasthomas The issue seems to have returned... Can you please check on your side and see i you can reproduce the bug?

@igorrocha commented on GitHub (Jan 6, 2020): @liyasthomas The issue seems to have returned... Can you please check on your side and see i you can reproduce the bug?

kerem commented

2026-03-16 13:55:50 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jan 7, 2020):

I couldn't reproduce the bug, everything seems to be working fine.

@liyasthomas commented on GitHub (Jan 7, 2020): I couldn't reproduce the bug, everything seems to be working fine.

kerem commented

2026-03-16 13:55:55 +03:00

Author

Owner

@igorrocha commented on GitHub (Jan 10, 2020):

I couldn't reproduce the bug, everything seems to be working fine.

False alarm on my side, my bad! Have a great weekend :)

@igorrocha commented on GitHub (Jan 10, 2020): > I couldn't reproduce the bug, everything seems to be working fine. False alarm on my side, my bad! Have a great weekend :)

kerem commented

2026-03-16 13:56:00 +03:00

Author

Owner

@W1M0R commented on GitHub (May 27, 2020):

I had the same problem, but realised that I used an outdated version from DockerHub.

@W1M0R commented on GitHub (May 27, 2020): I had the same problem, but realised that I used an outdated version from DockerHub.

kerem referenced this issue

2026-03-17 00:09:57 +03:00

[PR #183] [CLOSED] Add Device orientation and Update start_url in manifest #2463