Mouse events mostly do not reach BWindow in Mozilla, aswell as drawing messages

Description

When running Mozilla browsers in Haiku-OS, mouse is almost unusable.
At start mouse don't work, if you reload page with keyboard, it somewhat works, but flacky.
I have set printout with printf() statements on whole chain starting from BWindow::DispatchMessage(), through BView's MouseDown/Up/Moved and finishing in Mozilla's own widget message switch.

Observations.
1)Less than 1/4th of messages reaches BWindow::DispatchMessage in best case. But if it happens, all remaining chain is performing properly - those messages triggers BView's hooks and are going to mozilla internals.

2)Similar problem happens with drawing/invalidation chain.

3) Even when mouse "works" in Mozilla, it works only in certain areas of BWindow with misterious shape.

4)Keyboard input works properly.

5)There is problem even with debugging with printf() from Mozilla. It don't work until you put fflush(stdout); after each printf().

I've investigated this a bit, and it seems like the clipping is computed
incorrectly, at least it doesn't match what you see on screen.

I thought about clipping, but it raises question about Haiku's
appserver difference - does it submit mousse messages to to clipping
region only?

If so, that's weird in general, and also will break, IMHO,
compatibility with Set*EventMask() methods.

Now about setting clipping region. In code under our control, like
widget code, explicit clipping is set only inside Scroll procedure.
Also I tried to use ConstrainClippingRegion(0) to onscreen-views
before we send mozilla's internal message to redraw/reflow widget.
Didn't help.

But on other side, Mozilla sets clipping (using also BView's method)
by it's own quite intensively via our gfx-backend. I can try to put
some debug-statements in those gfx-methods, if you can tell me which
info can help you in investigations.

axeld, we were right in our suspects about clipping.
If I change code in gfx backend to set clipping region always to 0 in ConstrainClippingRegion instead using region provided by Mozilla - mouse starts work. But yeah, as expected, mozilla look is broken in such case. I can try to fix it in Mozilla code, there are some ideas here, but for sure, it is bug of explicit incompatibility with R5 and Dano

Fyysik, Axel and I have already found the problem in our app_server, I guess Axel will commit a fix soon. But not all is good yet, since there are definitely some race conditions with regards to clipping in the app_server. For example, I can observe one problem in WonderBrush with regards to ConstrainClippingRegion() in the navigation view (the background sometimes pops up for the split of a second when drawing). Maybe other problems are related to it as well. In any case, please don't "fix" any code in Firefox. It is a good stress test for our app_server, and it needs to handle it. :-)