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

[fyysik]

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().

[axeld]

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.

Is there something special on how you construct the view hierarchy in Mozilla (apart from naming everything "Child" :-))?

[fyysik]

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.

Also I can try to play with clipping myself in gfx-backend.

Call to ConstrainClippingRegion is here ​http://lxr.mozilla.org/mozilla1.8/source/gfx/src/beos/nsRenderingContextBeOS.cpp#366 it is called in each drawing primitive. And it gets info about region to clip from Mozilla's clipping structure which is also set via group of methods in same file, like this one: ​http://lxr.mozilla.org/mozilla1.8/source/gfx/src/beos/nsRenderingContextBeOS.cpp#295

[fyysik]

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

[stippi]

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. :-)

[axeld]

I've created a new bug for the clipping problems (#1719). I'm closing this bug as the mouse problems have been fixed in hrev23663.

[fyysik]

Nice to see that bug is fixed. At least I hope so. Dound place where it happens - when content of buffer bitmap with attached bview is copied to another bview - and destination view clipreg is set using source bitmap-view clipreg. code starts here ​http://lxr.mozilla.org/mozilla1.8/source/gfx/src/beos/nsRenderingContextBeOS.cpp#1498

Btw, I could fix problem from inside Mozilla code, by resetting destview clipping to 0 after this line: ​http://lxr.mozilla.org/mozilla1.8/source/gfx/src/beos/nsRenderingContextBeOS.cpp#1516

Probably I will publish that version too, inpite axeld fixed problem already, as I saw at IRC - just for comparison.

[fyysik]

Replying to stippi:

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. :-)

Heh, anyway, I published special version for unpatient testers and for comparison, according idea from my last comment: ​http://bebits.com/bob/21558/seamonkey-Haiku.zip