28260 - compose window jumps around the screen on send, and won't resize

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[Akkana Peck]

Bring up the compose window.  Resize it.  Type something and click send.

The window disappears, then appears at its original size somewhere else on the
screen, then disappears again.

The next time you bring up the compose window, it's gone back to its original
size.  Alec says windows need something like persist="x y width height" in order
to save their size.

Comment 1

[Jean-Francois Ducarroz]

right, I need to make the window location and size persitent

Comment 2

[Jean-Francois Ducarroz]

*** Bug 32987 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Bucksch (:BenB)]

The window disappears for the time, the send operation needs (this are often
several seconds for my dialup, autodial line). This is a bit irritating at
first. Is this necessary?

Comment 4

[Ben Bucksch (:BenB)]

> The window disappears for the time, the send operation needs



This is wrong.

Comment 5

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 6

[selmer (gone)]

Not beta2 stopper.  Marking M18.

Comment 7

[selmer (gone)]

Oops.  Really marking M18 now...

Comment 8

[Alec Flett]

akkana just brought up a very good reason this should be dogfood, if not nsbeta2
- on some systems (namely some unix window managers) when the window reappears
the second time, it is placed in a different place, or sometimes the user has to
place the window manually.

Sorry Jean-Francois!

Comment 9

[tenthumbs]

That would be me. I want to position windows myself so no program can put one
offscreen. With fvwm2 and the right settings Mozilla dismisses the compose
window and then recreates it so I see the wire frame attached to the mouse
pointer and Mozilla does nothing until I click the mouse. Truly irritating.

Comment 10

[leger]

Which window mgrs are users likely to encounter here?  Would like to push out to 
nsbeta3 if the user can still get to this.  How bad is it?

Comment 11

[Akkana Peck]

I almost always reposition compose windows from wherever they initially appear, 
so regardless of the window manager settings, if the window goes away then comes
back, it will reappear at a different place than it was when it disappeared. 
This doesn't prevent the message from sending, like it does in the interactive
placement case, it just makes us look stupid.  (Has anyone investigated why this
is happening only to the compose window and no other window, and whether it's
actually a difficult fix?  Maybe there's one line somewhere that says to close
the window before the send operation, which shouldn't be there?)

4Dwm (the IRIX wm) has interactive placement, like tenthumbs describes using on
fvwm2; I think any mwm-derived window manager offers that option.  I have no
idea what percentage of users actually turn on interactive placement, though,
nor what percentage of users use mwm-derived window managers.

Comment 12

[Ben Bucksch (:BenB)]

Enlightenment (standard window manager for Redhat, if nothing changed recently)
also offers this option, propably many more. It is not the default for most
window managers, though. I have no idea, how many people use this setting, too.

Yes, it makes us look very silly (just like the stupid roaming up/-download
status window in 4.x), but my personal opinion is, that we have much larger
problems on Unix, e.g. tree view performance or multiple item d&d.

Comment 13

[tenthumbs]

I have fvwm, WindowMaker, icewm, and Lesstif's version of mwm and they all offer
interactive/manual placement. There are some X apps that think they know where
they should be placed on the screen, or virtual desktop, so the window managers
offer ways to discipline recalcitrant apps.

Mozilla indeed looks awfully silly here.

Comment 14

[lchiang]

clearing NEED INFO since info has been provided for pdt team to evaluate.

Comment 15

[Peter Trudelle]

[nsbeta2-]

Comment 16

[Stephen Rasku]

*** Bug 41177 has been marked as a duplicate of this bug. ***

Comment 17

[sol]

Added "nsbeta3" and "correctness" keywords.

Comment 18

[scottputterman]

*** Bug 29059 has been marked as a duplicate of this bug. ***

Comment 19

[scottputterman]

Mail Triage is marking [nsbeta3-]

Comment 20

[varada]

Adding mail3 keyword.

Comment 21

[varada]

Linux Build 11/27/2000.
I dont see any jumping - but I do see that the positioning is not happening. I
checked in the localstore.rdf and found that though the ScreenX,ScreenY,width
and height are getting stored only the latter values i.e. width and height are
truly persistent. Including waterson in the CC to take a look at this problem.

Comment 22

[Ben Bucksch (:BenB)]

varada, if it jump around or how annoying this bug is depends highly on your
window manager and its configuration. The problem is that the window closes and
reopens in the first place.

Comment 23

[Jean-Francois Ducarroz]

Right, something wrong with our window manager on Linux. The same stuff works
fine on Mac & Windows.

Comment 24

[Ben Bucksch (:BenB)]

> The same stuff works fine on Mac & Windows

Maybe it's just that Mac and windows are not so configurable and thus much more
forgiving?

Comment 25

[Akkana Peck]

Agreed with Ben.  Under X, we cannot assume that we have the ability to set X
and Y -- many window managers don't allow that.  The window should not close
then reopen in the first place when the send is successful -- that's the cause
of this bug.  Reopening in the case of a failed send is not as bad, though it
would be much better if the window just stayed open until the send completed,
then closed (as 4.x did and as other mailers do).  It's jarring to see a window
go away then reappear.

Comment 26

[Ben Bucksch (:BenB)]

Not to start with the fact that an open Send window would be useful to provide
status feedback during send.
I guess, J-F original concern was to disallow editing during send, right? Is it
possible to make it read-only? I know, that would probably be some work, but
should be straight-forward.

Comment 27

[scottputterman]

marking nsbeta1-. cc'ing danm who sent a bunch of us a patch that might fix 
this.

Comment 28

[Dan M]

  I expect the patch Scott hints at just above won't affect this bug.
  Reading back over its history, I can add a couple of comments, but not much 
help. Yes, window size and position are persistent on certain windows, including 
messengercompose.xul (I imagine that's the window we're talking about). But the 
code that uses that information to position the window after creation is disabled 
on the linux builds, to not override the window manager's placement. (But the 
size information is acted on.)
  Umm, as for what's happening in this bug, I don't know, since I've never seen 
it happen. Every build on every machine I have, the Compose window is closed soon 
after punching Send, and never reappears. I suggest someone with a misbehaving 
build/system and source put a breakpoint in widget/src/gtk/nsWindow.cpp, 
nsWindow::Move(). I believe that all movement of windows executed by Mozilla goes 
through that single chokepoint.

Comment 29

[Akkana Peck]

Turns out nsWindow::Move is called many, many times on compose window startup (I
stopped counting and disabled the breakpoint after the fiftieth call) and is
called three times each time I mouse over the Send button in the compose window.
 That seems a little odd.

When I click send, after continuing past the three that came from mousing over
the Send button, the next one has the following stack trace (just the first few
calls, I can give more on request):
#0  nsWindow::Move (this=0x8804f08, aX=0, aY=0) at nsWindow.cpp:2447
#1  0x417986ad in nsView::SetPosition (this=0x8805500, aX=0, aY=0)
    at ../../dist/include/nsUnitConversion.h:138
#2  0x417ac4e9 in nsViewManager2::MoveViewTo (this=0x87f6dc0, aView=0x8805500,
    aX=0, aY=0) at nsViewManager2.cpp:1645
#3  0x40fd6c89 in nsContainerFrame::PositionFrameView (aPresContext=0x87f7380,
    aKidFrame=0x8a1c2d0, aView=0x8805500) at nsContainerFrame.cpp:390
#4  0x40ff3840 in nsHTMLReflowCommand::Dispatch (this=0x8c6e6d8,
    aPresContext=0x87f7380, aDesiredSize=@0xbfffeb40, aMaxSize=@0xbfffeb20,
    aRendContext=@0x8c6f378) at nsHTMLReflowCommand.cpp:142
#5  0x410238b3 in PresShell::ProcessReflowCommands (this=0x878f440,
    aInterruptible=0) at ../../../../dist/include/nsCOMPtr.h:641
#6  0x41021531 in PresShell::FlushPendingNotifications (this=0x878f440)
    at nsPresShell.cpp:4181
#7  0x40faec70 in nsEventStateManager::GenerateDragGesture (this=0x8a51c90,
    aPresContext=0x87f7380, aEvent=0xbffff1e0)
    at ../../../dist/include/nsCOMPtr.h:648
#8  0x40fab673 in nsEventStateManager::PreHandleEvent (this=0x8a51c90,
    aPresContext=0x87f7380, aEvent=0xbffff1e0, aTargetFrame=0x89cf478,
    aStatus=0xbffff0ac, aView=0x8805500) at nsEventStateManager.cpp:300
#9  0x41022b86 in PresShell::HandleEventInternal (this=0x878f440,
    aEvent=0xbffff1e0, aView=0x8805500, aFlags=1, aStatus=0xbffff0ac)
    at ../../../../dist/include/nsCOMPtr.h:641
#10 0x41022887 in PresShell::HandleEvent (this=0x878f440, aView=0x8805500,
    aEvent=0xbffff1e0, aEventStatus=0xbffff0ac, aForceHandle=1,
    aHandled=@0xbffff038) at nsPresShell.cpp:4811
#11 0x41798469 in nsView::HandleEvent (this=0x8805500, event=0xbffff1e0,
    aEventFlags=28, aStatus=0xbffff0ac, aForceHandle=1, aHandled=@0xbffff038)
    at nsView.cpp:366
#12 0x417abc6b in nsViewManager2::DispatchEvent (this=0x87f6dc0,
    aEvent=0xbffff1e0, aStatus=0xbffff0ac) at nsViewManager2.cpp:1437
#13 0x41797b30 in HandleEvent (aEvent=0xbffff1e0) at nsView.cpp:67

Continuing past this gets two with traces like:
#0  nsWindow::Move (this=0x8ac8248, aX=19, aY=110) at nsWindow.cpp:2447
#1  0x417986ad in nsView::SetPosition (this=0x8ac81b8, aX=285, aY=1650)
    at ../../dist/include/nsUnitConversion.h:138
#2  0x4179ea60 in nsScrollPortView::SetPosition (this=0x8ac81b8, aX=285,
    aY=1650) at nsScrollPortView.cpp:119
#3  0x417ac4e9 in nsViewManager2::MoveViewTo (this=0x87f6dc0, aView=0x8ac81b8,
    aX=285, aY=1650) at nsViewManager2.cpp:1645
#4  0x40fd6c89 in nsContainerFrame::PositionFrameView (aPresContext=0x87f7380,
    aKidFrame=0x8b3f73c, aView=0x8ac81b8) at nsContainerFrame.cpp:390
#5  0x40fd75ba in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8b3f7ec) at nsContainerFrame.cpp:752
#6  0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8b9ca44) at nsContainerFrame.cpp:756
#7  0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8b3f3d0) at nsContainerFrame.cpp:756
#8  0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8a1cc8c) at nsContainerFrame.cpp:756
#9  0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8a1cbfc) at nsContainerFrame.cpp:756
#10 0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8a1d0ac) at nsContainerFrame.cpp:756
#11 0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8a1cb6c) at nsContainerFrame.cpp:756
#12 0x4120dd73 in nsBox::SetBounds (this=0x8a1cba4, aState=@0xbfffe690,
    aRect=@0xbfffdff0) at nsBox.cpp:568
#13 0x41215766 in nsSprocketLayout::Layout (this=0xbfffe020, aBox=0x89fbc74,
    aState=@0xbfffe690) at nsSprocketLayout.cpp:376
Followed by this one:
#0  nsWindow::Move (this=0x8b40a48, aX=0, aY=256) at nsWindow.cpp:2447
#1  0x417986ad in nsView::SetPosition (this=0x8b40968, aX=0, aY=3840)
    at ../../dist/include/nsUnitConversion.h:138
#2  0x417ac4e9 in nsViewManager2::MoveViewTo (this=0x87f6dc0, aView=0x8b40968,
    aX=0, aY=3840) at nsViewManager2.cpp:1645
#3  0x40fd6c89 in nsContainerFrame::PositionFrameView (aPresContext=0x87f7380,
    aKidFrame=0x8b3f390, aView=0x8b40968) at nsContainerFrame.cpp:390
#4  0x40fd75ba in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x89cf850) at nsContainerFrame.cpp:752
#5  0x40fd75c8 in nsContainerFrame::PositionChildViews (
    aPresContext=0x87f7380, aFrame=0x8a1c89c) at nsContainerFrame.cpp:756
#6  0x4120dd73 in nsBox::SetBounds (this=0x8a1c8d4, aState=@0xbfffe690,
    aRect=@0xbfffe3b0) at nsBox.cpp:568
#7  0x41215766 in nsSprocketLayout::Layout (this=0xbfffe3e0, aBox=0x8a1c3d4,
    aState=@0xbfffe690) at nsSprocketLayout.cpp:376
#8  0x41214288 in nsContainerBox::DoLayout (this=0x8a1c3d4, aState=@0xbfffe690)
    at ../../../../dist/include/nsCOMPtr.h:648
#9  0x41222729 in nsBoxFrame::DoLayout (this=0x8a1c39c, aState=@0xbfffe690)
    at nsBoxFrame.cpp:984
#10 0x4120e8c9 in nsBox::Layout (this=0x8a1c3d4, aState=@0xbfffe690)
    at nsBox.cpp:1000
#11 0x41217f00 in nsStackLayout::Layout (this=0x85a6ae8, aBox=0x8a1c344,
    aState=@0xbfffe690) at nsStackLayout.cpp:255
#12 0x41214288 in nsContainerBox::DoLayout (this=0x8a1c344, aState=@0xbfffe690)
    at ../../../../dist/include/nsCOMPtr.h:648
#13 0x41222729 in nsBoxFrame::DoLayout (this=0x8a1c30c, aState=@0xbfffe690)
    at nsBoxFrame.cpp:984

There are thirteen more calls to nsWindow::Move before the compose finally
finishes.  I bet you don't want to see the stack traces for all of them. :-)
Let me know which one you want, and what information you're after, or come by my
cube sometime and we can debug it.

Comment 30

[Jean-Francois Ducarroz]

We are not hidding the compose window anymore while sending. Therefore no more
jumping around. WFM

Comment 31

[laurel]

Worksforme with oct 5 0.9.4 branch build, linux rh6.2.