Frames, as used by mailnews and by the browser sidebar, have the following problems on resize. Not sure which of these are linux specific and which are xp, since my nt build failed today. 1. No feedback -- need a wireframe, like 4.* has, because continuous drawing isn't fast enough to show that anything is being resized. Even if gfx isn't providing xor yet (bug 3886), just drawing black/white would be better than what we do now. 2. When the toplevel window is resized, all the frames forget that they were resized and go back to their original size. 3. Frames can get into a mode where they resize as soon as the mouse comes near their borders, no mouse down -- perhaps a mouse-up event is getting lost and the frame resize code still thinks there was a mouse down? Maybe it needs to check for button down on every mouse motion event?

theres at least 3 unique bugs in here. 1. is the performance problem which im working on. 2. is an xp issue, should be assigned to pollmann maybe 3. is a bug in the gtk widget code which should be assigned to me. thanks

Split #2 into a separate bug, http://bugzilla.mozilla.org/show_bug.cgi?id=6715

Split #3 into http://bugzilla.mozilla.org/show_bug.cgi?id=7073. Ramiro, you can consider this bug report to refer to #1, reassigning to you.

Putting on [Perf] radar

Reassigning to pavlov cause he likes bugs. Adding blizzard to cc. I think the stuff blizzard is working on might help in this area. The last time i debugged this, the problem was that the zillions of "draw" and "size_allocate" signals were slowing down the gesture of dragging the frame border.

sidebar and mailnews use the splitter.. this works. frames can be resized, but it is awfully slow on linux. marking this bug fixed.

Reopening. I still see the same old problems: 1. It never works the first time: I have to try several times before dragging on the splitter will actually resize the pane. 2. Sometimes after clicking on the splitter unsuccessfully, then moving the mouse away and back to try again, I find that it's now in "drag mode" even though the mouse button is no longer down -- as if it never got the button up event. This seldom happens with the vertical splitter between the thread and message panes, but happens nearly every time with the horizontal splitter between the folder and thread/message panes.

Clearing FIXED resolution due to reopen of this bug.

I don't see #1 (in the second list) at all, both horiz. and vertical splitters in the Mail window work for me, first time, every time. I'm not sure what you mean by 'clicking unsuccessfully' in #2. When I click on the splitter, it toggles between open and close. This is using today's opt comm bits on RH6.0 It is possible to drag the horizontal mail splitter, release, then drag again before it has actually moved. I was able to get into the state described by doing this repeatedly, but it worked itself out after clicking elsewhere. This bug is now a mess, with 2 separate numbered lists of symptoms, some of which have been broken out into separate bugs. After the first list, this bug was supposed to be about the lack of feedback, but it was then considered a performance bug (although that wasn't the original problem), then reopened for two other reasons, at least one of which I can't reproduce. Due to all the confusion, I'm resolving this as invalid, please file separate bugs as needed for each unique problem that still remains.