WebPositive hangup when scrolling page

[ronald-scheckelhoff-trac]

When visiting www.google.com, WebPositive became unresponsive to all input. After attaching to it with the debugger, the debug report was grabbed (see attachment).

[ronald-scheckelhoff-trac]

Debugger report file

[ronald-scheckelhoff-trac]

This happened while using hrev 49682

[ronald-scheckelhoff-trac]

The exact same thing happened today, going to ​https://www.github.com/haikuports/haikuports. The debug report looks almost identical. So - it's randomly repeatable.

[ronald-scheckelhoff-trac]

This ticket should be changed to have the Webpositive component attribute. Have to get in the habit. Sorry.

[pulkomandy]

I noticed this too, it will happen randomly when scrolling the page. The code for this is not very good as there are things done both in the main and in the window thread; however I could not understand the exact problem (I think it is a lock order inversion, involving the main looper lock, the window looper lock, and the offscreen bitmap lock). Maybe rewriting the code so all the scrolling happens in the view thread, and the main thread just forwards the scroll request, would work. But all the drawing should still happen in the main thread because WebKit is designed that way...

[ttcoder]

@pulkomandy (I'm posting the following distinct issue just in case it sheds light on this -- or other -- issue here, otherwise ignore it):

For a couple months of hrevs now, there is a new, deterministic bug in W+ (or maybe it's a different aspect of an existing bug ?). To replicate:

• simply open a big image's URL (NOT an html page that contains images in it, but a direct URL directly to the image). A good example is the KDL screenshots that sometimes get posted to Trac here.
• hover the mouse pointer: it turns into a "magnifgying glass" pointer; left-click to "zoom in" on any part of the image: the zoomed image shows up, but W+ won't respond any more after that. Web+ never fails to lock up there.

Not sure if that deserves its own ticket

[pulkomandy]

Please open a new ticket, if the backtrace is similar we can always close it as duplicate.

[pulkomandy]

(In #11879) Without a bugreport, I assume this is a duplicate of #12420.

[pulkomandy]

Haven't seen this one happen in a while, I think it's fixed now.