Akkana Peck Reporter
	Description • 26 years ago

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?

	ramiro
	Comment 1 • 26 years ago

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

	Akkana Peck Reporter
	Comment 2 • 26 years ago

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

	Peter Trudelle
	Comment 3 • 26 years ago

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.

	leger
	Comment 4 • 26 years ago

Putting on [Perf] radar

	ramiro
	Comment 5 • 25 years ago

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.

	Stuart Parmenter Assignee
	Comment 6 • 25 years ago

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

	Akkana Peck Reporter
	Comment 7 • 25 years ago

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.

	leger
	Comment 8 • 25 years ago

Clearing FIXED resolution due to reopen of this bug.

	Peter Trudelle
	Comment 9 • 25 years ago

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.