Gitea doesn&#39;t open more than 5 tabs in browser #5588

@lunny commented on GitHub (Jun 19, 2020):

can't reproduce in https://gitea.com

@lunny commented on GitHub (Jun 19, 2020): can't reproduce in https://gitea.com

GiteaMirror commented

@lakostin commented on GitHub (Jun 19, 2020):

Updated description.

@lakostin commented on GitHub (Jun 19, 2020): Updated description.

GiteaMirror commented

@wkobiela commented on GitHub (Jun 19, 2020):

@lakostin
Just checked myself, Gitea 1.12.0, GIT 2.26.2, MySQL, hosted on Synology.
Created PR with >5 commits, opened PR and each commit multiple times. No issues.

@wkobiela commented on GitHub (Jun 19, 2020): @lakostin Just checked myself, Gitea 1.12.0, GIT 2.26.2, MySQL, hosted on Synology. Created PR with >5 commits, opened PR and each commit multiple times. No issues.

GiteaMirror commented

@lakostin commented on GitHub (Jun 19, 2020):

I have this isssue on multiple instances and even on different versions. All served by docker btw

@lakostin commented on GitHub (Jun 19, 2020): I have this isssue on multiple instances and even on different versions. All served by docker btw

GiteaMirror commented

@chxseh commented on GitHub (Jun 19, 2020):

Can confirm, opening any new tabs after 6 have loaded for me results in awaiting for socket. Hosting on Docker as well.

@chxseh commented on GitHub (Jun 19, 2020): Can confirm, opening any new tabs after 6 have loaded for me results in awaiting for socket. Hosting on Docker as well.

GiteaMirror commented

@dexterxx-pl commented on GitHub (Jun 19, 2020):

I had same issue here, just after updating to v1.12.
It's not related just to PR's - in my case I've just opened new tabs of issues of my project - loading just stucks... and it stucks for many minutes.

CPU usage stays at typical level, logs shows that database (MySQL in my case) also respond in typical time.

Now I've just figured out, that restarting gitea didn't solved problem, but restarting proxy (apache2) does.

After restarting I cannot now reproduce it 👎

@lakostin are you using proxy at front of gitea?

@dexterxx-pl commented on GitHub (Jun 19, 2020): I had same issue here, just after updating to v1.12. It's not related just to PR's - in my case I've just opened new tabs of issues of my project - loading just stucks... and it stucks for many minutes. CPU usage stays at typical level, logs shows that database (MySQL in my case) also respond in typical time. Now I've just figured out, that restarting gitea didn't solved problem, but restarting proxy (apache2) does. After restarting I cannot now reproduce it :-1: @lakostin are you using proxy at front of gitea?

GiteaMirror commented

@chxseh commented on GitHub (Jun 19, 2020):

@dexterxx-pl Tried restarting my proxy in front of gitea to no effect.

@chxseh commented on GitHub (Jun 19, 2020): @dexterxx-pl Tried restarting my proxy in front of gitea to no effect.

GiteaMirror commented

@lafriks commented on GitHub (Jun 20, 2020):

I think it is related to events endpoint that uses sockets for getting events about new notifications. We should probably somehow limit sockets count per user probably

@lafriks commented on GitHub (Jun 20, 2020): I think it is related to events endpoint that uses sockets for getting events about new notifications. We should probably somehow limit sockets count per user probably

GiteaMirror commented

@deptyped commented on GitHub (Jun 20, 2020):

Same problem. But I could not reproduce this issue without a reverse proxy server (nginx in my case).
By the way, in Firefox pages stop loading after five clicks on the site in one tab.

UPD: Using http2 in nginx solved the problem

@deptyped commented on GitHub (Jun 20, 2020): Same problem. But I could not reproduce this issue without a reverse proxy server (nginx in my case). By the way, in Firefox pages stop loading after five clicks on the site in one tab. **UPD**: Using http2 in nginx solved the problem

GiteaMirror commented

@zeripath commented on GitHub (Jun 20, 2020):

Yeah I suspect this is EventSource issues.

@zeripath commented on GitHub (Jun 20, 2020): Yeah I suspect this is EventSource issues.

GiteaMirror commented

@zeripath commented on GitHub (Jun 20, 2020):

So I don't think this is the server holding things up but rather the browser. It looks like Firefox is blocking instead of just failing out.

@zeripath commented on GitHub (Jun 20, 2020): So I don't think this is the server holding things up but rather the browser. It looks like Firefox is blocking instead of just failing out.

GiteaMirror commented

@confusedsushi commented on GitHub (Jun 21, 2020):

I can confirm this. It happened first after upgrading to 1.12. I am running gitea on Windows 10 2004 with an apache reverse proxy on Ubuntu 18.04.

I am able to reproduce this with Firefox and Chrome.

@confusedsushi commented on GitHub (Jun 21, 2020): I can confirm this. It happened first after upgrading to 1.12. I am running gitea on Windows 10 2004 with an apache reverse proxy on Ubuntu 18.04. I am able to reproduce this with Firefox and Chrome.

GiteaMirror commented

@zeripath commented on GitHub (Jun 21, 2020):

Can anyone reproduce this on try?

@zeripath commented on GitHub (Jun 21, 2020): Can anyone reproduce this on try?

GiteaMirror commented

@Governa commented on GitHub (Jun 22, 2020):

Can anyone reproduce this on try?

It seems I do. Both in Firefox and in Chromium.

I just have to Login and from the Dashboard open multiple commits in tabs. If then I click on "View source" it will not load until I close enough(about 5 tabs are left open) tabs.

It seems to be about 5 tabs in each browser, as I could test Chromium while Firefox tabs were still open.

@Governa commented on GitHub (Jun 22, 2020): > Can anyone reproduce this on try? It seems I do. Both in Firefox and in Chromium. I just have to Login and from the Dashboard open multiple commits in tabs. If then I click on "View source" it will not load until I close enough(about 5 tabs are left open) tabs. It seems to be about 5 tabs in each browser, as I could test Chromium while Firefox tabs were still open.

GiteaMirror commented

@lakostin commented on GitHub (Jun 24, 2020):

Reproduced also in Gitea Version: 1.12.1 running with systemd.
Do not use any proxy server in front.

@lakostin commented on GitHub (Jun 24, 2020): Reproduced also in Gitea Version: 1.12.1 running with systemd. Do not use any proxy server in front.

GiteaMirror commented

@flozzone commented on GitHub (Jun 24, 2020):

Also Reproducible

version: 1.12.1
proxy: apache 2.4
env: docker container

5-6 clicks and gitea hangs, but when I open a private window and login, gitea works and is accessible again.
Then I tried to reproduce this issue within a private window -> no chance
Its interesting that in the debugger inside a private window I can see connections to /user/events (See the curl cmd below) while navigating, but not within a regular browser tab
When doing the last click, no communications occur (Checked proxy access logs)

curl 'https://GITEA_HOST/user/events' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0' -H 'Accept: text/event-stream' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en-US; i_like_gitea=33dxxxxxxxxx270; _csrf=zIz1_5HrJzMfqWC4XXXXXXXXXXXXXXXXXXXXXOTQyNw' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

@flozzone commented on GitHub (Jun 24, 2020): Also Reproducible version: 1.12.1 proxy: apache 2.4 env: docker container * 5-6 clicks and gitea hangs, but when I open a private window and login, gitea works and is accessible again. * Then I tried to reproduce this issue within a private window -> no chance * Its interesting that in the debugger inside a private window I can see connections to /user/events (See the curl cmd below) while navigating, but not within a regular browser tab * When doing the last click, no communications occur (Checked proxy access logs) `curl 'https://GITEA_HOST/user/events' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0' -H 'Accept: text/event-stream' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: lang=en-US; i_like_gitea=33dxxxxxxxxx270; _csrf=zIz1_5HrJzMfqWC4XXXXXXXXXXXXXXXXXXXXXOTQyNw' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'`

GiteaMirror commented

@mind-overflow commented on GitHub (Jun 24, 2020):

This also happens while normally browsing Gitea, you do not need to open 5 different tabs at the same time. I have ran into this problem just by navigating through my commits and repository files, and have been running into it since at least version 1.11. I am now using 1.12.1 with the same identical problem.

Gitea is running behind an Apache2 reverse proxy, no docker. MySQL database. Ubuntu 20.04 LTS.

@mind-overflow commented on GitHub (Jun 24, 2020): This also happens while normally browsing Gitea, you do not need to open 5 different tabs at the same time. I have ran into this problem just by navigating through my commits and repository files, and have been running into it since at least version 1.11. I am now using 1.12.1 with the same identical problem. Gitea is running behind an Apache2 reverse proxy, no docker. MySQL database. Ubuntu 20.04 LTS.

GiteaMirror commented

@42wim commented on GitHub (Jun 25, 2020):

I can also reproduce this (on gitea 1.12.1), the /user/events keep pending.
Related to https://developer.mozilla.org/en-US/docs/Web/API/EventSource and HTTP/2.

I've patched my own gitea to disable javascript going to /user/events and everythings works fine now.
There should be an option to disable this when people don't have access to HTTP/2 loadbalancers.

@42wim commented on GitHub (Jun 25, 2020): I can also reproduce this (on gitea 1.12.1), the `/user/events` keep pending. Related to https://developer.mozilla.org/en-US/docs/Web/API/EventSource and HTTP/2. I've patched my own gitea to disable javascript going to `/user/events` and everythings works fine now. There should be an option to disable this when people don't have access to HTTP/2 loadbalancers.

GiteaMirror commented

2025-11-02 06:30:02 -06:00

@westhom commented on GitHub (Jun 27, 2020):

I was seeing this issue in Firefox / Gitea 1.12.1, clicking around gitea a bunch would eventually cause requests to hang and never complete, essentially freezing the app. I noticed in the network debugger a lot of the requests were being fulfilled by the Service Worker.

I was able to fix my issue by going into about:debugging and unregistering the service worker for my gitea domain, then refreshing the tab. Now I can't reproduce the issue. The service worker appeared in the list after I re-opened for the first time, but all seems good now.

@westhom commented on GitHub (Jun 27, 2020): I was seeing this issue in Firefox / Gitea 1.12.1, clicking around gitea a bunch would eventually cause requests to hang and never complete, essentially freezing the app. I noticed in the network debugger a lot of the requests were being fulfilled by the Service Worker. I was able to fix my issue by going into `about:debugging` and unregistering the service worker for my gitea domain, then refreshing the tab. Now I can't reproduce the issue. The service worker appeared in the list after I re-opened for the first time, but all seems good now.

GiteaMirror commented

@ratuka commented on GitHub (Jun 29, 2020):

Same here with Firefox and Chrome too.

@ratuka commented on GitHub (Jun 29, 2020): Same here with Firefox and Chrome too.

GiteaMirror commented

2025-11-02 06:30:02 -06:00

@zeripath commented on GitHub (Jun 29, 2020):

Sorry about this. This one is my fault.

There is a workaround:

~~[ui.notification]~~
~~EVENT_SOURCE_UPDATE_TIME=0~~

or use HTTP/2.0.

I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review.

Unfortunately the setting doesn't work due to a misunderstanding on my behalf. My suspicion was the EventSource would not open if you hit the tab limit not - that it would prevent opening new tabs - and although I tested with opening multiple tabs it didn't cause these problems.

This code has been part of master for quite some time - I don't understand why it was only on release of Gitea 1.12 that this problem was noticed. Presumably try runs on HTTP/2.0?

@zeripath commented on GitHub (Jun 29, 2020): Sorry about this. This one is my fault. There is a workaround: ~~[ui.notification]~~ ~~EVENT_SOURCE_UPDATE_TIME=0~~ ~~or~~ use HTTP/2.0. I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review. --- Unfortunately the setting doesn't work due to a misunderstanding on my behalf. My suspicion was the EventSource would not open if you hit the tab limit not - that it would prevent opening new tabs - and although I tested with opening multiple tabs it didn't cause these problems. This code has been part of master for quite some time - I don't understand why it was only on release of Gitea 1.12 that this problem was noticed. Presumably try runs on HTTP/2.0?

GiteaMirror commented

2025-11-02 06:30:02 -06:00

@mind-overflow commented on GitHub (Jun 29, 2020):

Sorry about this. This one is my fault.

There are two workarounds:
[ui.notification]
EVENT_SOURCE_UPDATE_TIME=0
or use HTTP/2.0.

I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review.

EDIT: Looks like Firefox had cached some settings. I was still using HTTP 1.1 with my old session, however in incognito mode (and thus clearing the cookies too) switched me to HTTP 2.0, fixing the problem.

Very weird, since my server allows HTTP 2.0 connections and I still manage to have this issue... Are you sure about the second fix? I'm starting to doubt that my configuration could be faulty, even though the Firefox dev console says I'm using HTTP 2.0...

@mind-overflow commented on GitHub (Jun 29, 2020): > Sorry about this. This one is my fault. > > There are two workarounds: > > > ```ini > [ui.notification] > EVENT_SOURCE_UPDATE_TIME=0 > ``` > > or use HTTP/2.0. > > I've finally managed to hack up a fix and will push up a PR to push the EventSource stuff into a SharedWorker but it will need review. EDIT: Looks like Firefox had cached some settings. I was still using HTTP 1.1 with my old session, however in incognito mode (and thus clearing the cookies too) switched me to HTTP 2.0, fixing the problem. _Very weird, since my server allows HTTP 2.0 connections and I still manage to have this issue... Are you sure about the second fix? I'm starting to doubt that my configuration could be faulty, even though the Firefox dev console says I'm using HTTP 2.0..._

GiteaMirror commented

@chxseh commented on GitHub (Jun 29, 2020):

[ui.notification]
EVENT_SOURCE_UPDATE_TIME=0

Doesn't appear to work for me, not sure if I just did something wrong.. Will try and figure out switching to HTTP/2.0.

@chxseh commented on GitHub (Jun 29, 2020): > ```ini > [ui.notification] > EVENT_SOURCE_UPDATE_TIME=0 > ``` Doesn't appear to work for me, not sure if I just did something wrong.. Will try and figure out switching to HTTP/2.0.

GiteaMirror commented

@zeripath commented on GitHub (Jun 30, 2020):

@ChaseHall try -1 instead of 0?

@zeripath commented on GitHub (Jun 30, 2020): @ChaseHall try -1 instead of 0?

GiteaMirror commented

@chxseh commented on GitHub (Jun 30, 2020):

@zeripath -1 just results in a 503. Nothing useful in docker logs about it..

@chxseh commented on GitHub (Jun 30, 2020): @zeripath -1 just results in a 503. Nothing useful in docker logs about it..

GiteaMirror commented