Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#11879 closed bug (duplicate)

Web+ hang in itself

Reported by: AlienSoldier Owned by: pulkomandy
Priority: high Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: #12420 Blocking: #12974
Has a Patch: no Platform: All

Description

It does not crash or anything, i can still navigate the tabs and the menu but i no longer can move the slide bars/arrows and can't have write anything in the web rendering section and neither can i click a link in it.

I think i saw that behavior before but now it make the browser unusable on a daily use. I cant seem to pinpoint what trigger this, it seem random to me (it seem to appear at least 1 time per hour on average). hrev48839

Change History (5)

comment:1 by pulkomandy, 4 years ago

Blocked By: 12420 added
Resolution: duplicate
Status: newclosed

Without a bugreport, I assume this is a duplicate of #12420.

comment:2 by AlienSoldier, 4 years ago

This still happen in webkit 1.5.2 As the app does not crash, it just hang there i don't have a report. I am not sure 100% but i think it happen more often with certain sites but it seem to only increase the probablility and seem to be able to do it anywhere, like this one for example: videogamecritic.com just loading that site and letting it around in a tab is often enough to get the browser to hang without any additional action. At that point i can add that the screen still redraw if we send the browser offscreen or if we pass another window on top of it.

comment:3 by AlienSoldier, 3 years ago

That ticket should not be closed, i still have that problem, using build 50454 now (it always did that problem all that time). It was market as duplicate and that one is taged as fixed but mine still is a problem, so something else is at work.

comment:4 by AlienSoldier, 3 years ago

https://dev.haiku-os.org/ticket/12974 look to be related to my problem.

comment:5 by pulkomandy, 3 years ago

Blocking: 12974 added

(In #12974) This is quite easy to reproduce anyway, on various websites.

The problem is that we try to stop an HTTP request, and wait forever for it to stop. There were some attempts to mitigate the issue in the code but it doesn't work reliably. Fixing this properly may need yet another redesign of the HTTP library.

Note: See TracTickets for help on using tickets.