User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre The nsView::DoResetWidgetBounds method has a wrong behavior with <panel>. Leading many calls to widget Resize/Move even when the panel did not move. The method compares the current bounds and the widget bounds to see if it is needed to resize or move the window. The current bounds is retrieved by the nsWindow::GetBounds methods. This method returns an offset of the parent's screen origin for window with parent (which is the case of the panel). And this is never the same as the widget bounds. It causes the code to call move/resize every time there is a pending update of the window. Reproducible: Always Steps to Reproduce: 1. Open a panel (like the inspector panel) 2. Move the mouse over a button in the window. Actual Results: The method nsWindow::Move / nsWindow::Resize are called. Expected Results: None of the methods should be called since the window has not move.

With this patch, the bounds checking is correct and window are no longer moved/resized if it's not needed. This patch works for Windows. For linux, it introduces quirks when the window is resized. I will have a look at it.

I think the comment there says that GetScreenBounds is more expensive on Linux than GetBounds. So maybe you should keep that optimization, i.e. do the IsEmpty() check on GetBounds, and only call GetScreenBounds after that. The resize quirks may be caused by the other thing that the comment mentions: On Linux, the position that GetScreenBounds returns may not be up-to-date, because window operations are asynchronous there.

Doesn't seem like this should block --- not a regression, not a major bug.

DoResetWidgetBounds now uses GetClientBounds, and the comment about GetClientBounds in nsIWidget says that the coordinates should be screen coordinates for toplevel and popup widgets. I *think* all the major widget implementations respect this. If they do not it is a bug and should be fixed.