Created attachment 199004[details][diff][review]
patch
additionally cleaned up OnResize() method:
1)in BeOS client area bounds are same as ::Bounds().
2)no need to call mView->Bounds() and lock looper once more - it was done in
GetBounds()

I think we should not duplicate code so the
for (nsIWidget* kid = mFirstChild; kid; kid = kid->GetNextSibling()) ...
should be in a private call, (maybe inlined). Also while we are fixing Move and
Resize I think we should skip the if's mustUnlock and haveWindow and just set
the booleans to the expressions inside the if();
So that:
if(mView->LockLooper())
mustUnlock = true
would be
mustUnlock = mView->LockLooper();

Created attachment 199550[details][diff][review]
patch, wider usage of HideKids method
Changes over previous version
Refactored HideKids() method (hiding-unhiding ALL VISIBLE children now),
added mIsScrolling trigger to control whether HideKids to be called, using
HideKids in Scroll() together with trigger, reducing locking usage.
Both resize and scrolling turns better (especially scrolling) with this patch
(see ),
last remaining scrolling problem is now XUL-knob, whith ugly lag in update (as
using asynchronous version of update)

Little explanation to whom it may concern about scrolling part of patch.
nsWindow::Scroll() triggers ON flag mIsScrolling and and HideKids hides (only
those) children which intersects with current mBounds.
nsWindow::Update() unhides children (again, only visible) if msIsScrolling is
OFF. It means - when this method is called by something other than gkview Scroll().
Then Update() siwtches mIsScrolling OFF unconditionally. So, if no Scroll is
called, with next Update() call children will be visible again.
All that prevents very intensive Hide/Show sequence during scroll, so prevents
same huge amount of unneccessary Invalidate/Repaint events.

I got strange behaviour with context menus on some sites with crappy code and
slow download which imports advertising into iframes.
Sometimes right-clicking on that iframe causes context menu to appear far away
from click point. I suspect that we should remove HideKids from :Move() but
cannot be sure atm about reason and remedy, because i lack good testcase:(

Comment on attachment 199550[details][diff][review]
patch, wider usage of HideKids method
Requesting approval for the MOZILLA_1_8_BRANCH. This is a BeOS only change and
will therefore not pose any risk for the other platforms.

it appears that in combination with scroll HideKids used in Move() sometimes
brings bug on page with IFRAMEs. While right-click on some IFRAMEs works
correctly, other cause strnage thing - context menu appears far away from click
point. So we will remove it for now

Created attachment 199943[details][diff][review]
patch
current visibility control code is insufficient it may cause strange effects
with sites with slowly imported IFRAME content.
Let this problem for future

Comment on attachment 199980[details][diff][review]
cmmulative patch
Requesting approval to land in the MOZILLA_1_8_BRANCH. This is a BeOS only change and will not affect the other platforms in any way.