The layout engine is trying to create windows that are larger than the X window coordinate system will allow. As per some of the offline discussions that I have had with travis and kmcclusk, if you remove the NS_SIZE event from the nsIWidget::Resize() method, window resizing _should_ work. Unfortunately, there are some instances where it doesn't. Here's a concrete example: uncomment this code from nsWindow::Resize in widget/src/gtk/nsWindow.cpp:1108: GtkAllocation alloc; alloc.width = aWidth; alloc.height = aHeight; alloc.x = 0; alloc.y = 0; //handle_size_allocate(mWidget, &alloc, this); this will stop the resize event from getting fired. Try opening an IMAP folder in mailnews. When the password dialog pops up it will pop up with a size of 1200x1600. If you use the SUPERWIN branch, it will crash outright. I think that the GtkWidget code has checks for size overruns; my code doesn't. A patch for this that I put together and submitted 4 days ago is attached on a seperate entry.

I don't understand the issues with this bug. It seems you're involved so I'm reassigning the bug

*tap* *tap* *tap* Is this think still on?

The NS_SIZE still needs to generated to resynchronize the cross-platform view system with the native widgets size. The commenting out of the handle_size_allocate prevents this from happening. The patch which fixes the bad sizes compensates for this by explicitly setting the dimensions of the view to match the widget instead of relying the NS_SIZE message, which has been suppressed. My guess is the real problem is the handle_size_allocate should only be registered for the top-level window. None of the child windows should use the handle_size_allocate callback to generate NS_SIZE events. Instead.. the nsWindow::Resize should generate the NS_SIZE event synchronously for child windows. (This will allow the view system to synchronize it's dimensions to the native child window.) There may be a problem with sending the NS_SIZE event synchronously since the native widget has not really changed size yet. The desired behavior is the following: User resizes the window. A single NS_SIZE is generated for the top-level window. The XPCODE may make calls to nsIWidget::Resize to change the dimensions of child windows . If the nsIWidget::Resize is called from the XPCODE the child window should generate a single NS_SIZE. The NS_SIZE generated by the child window is used to synthronize the dimensions of the view with the native window. NS_SIZE should only be generated in two circumstances. The top level window has been resized by the user. (A single NS_SIZE is sent to the top-level window only. None of the child windows will have a NS_SIZE generated.) A child window has been resized programmatically. A single NS_SIZE is sent to the window that has changed size.

When you say "desired behavior" do you mean that if I implement what you describe that it should work or do you expect it not to work and you need to make XP changes to make it operate as desribed?

I've tried implementing what you describe here and it works reasonably well. Some intrinsically sized windows jump around and come up with the wrong size, though.

and it's a little slower, too...

If you implement as described I expect it to work. I wonder if the problem with sending the NS_SIZE's synchronously is that the XPCODE asks for the size of the child window in response to the NS_SIZE event and the native window has not really taken the new size yet because it is waiting for a "configure" event?

That's very likely. I have a question, though. Is this a good long term solution? Or would it make more sense to have the view bounds updated by the called as my patch does or do you want it updated by the widget code?

It really needs to be updated by the Widget code. There can child windows which sit below the view that is resized by the presentation shell that also need to be updated when their size has been changed by a call to nsWidget::Resize. I think the main issue is that we need to be able to access any of the nsIWidget's methods from the NS_SIZE callback handler. The handle_size_allocate callback provides a "safe" place to dispatch the NS_SIZE events, but it dispatches too many NS_SIZE events.

Reassigning to pavlov. He mentioned he has a solution for this.

targetting m13

I haven't seen this behaviour in a very long time. It might safe to close this. If no one else has seen it, close it.

marking fixed.

Marking verified per last comments.

Marking verified per last comments.