222502 - last closed window position not remembered at restart

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Felix Miata]

ID: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4.1) Gecko/20031014. Behavior
dates back to fix checkin for bug 199507.

To reproduce:
1-Open initial browser window at a position somewhat distant from 0,0
2-Help -> About Mozilla
3-Close 2nd window
4-Close original window
5-Start browser

Actual results:
1-Window opens at postition in 2 & 3 above

Expected results:
1-Window opens at postition in 1 & 4 above

For me normally #2 above opens at 0,0, while #1 is kept around 100px to the
right of 0,0, and at full screen height.

Comment 1

[jhp (no longer active)]

Mike, was this fixed under another bug, or was the patch never checked in?

Comment 2

[Felix Miata]

Something fixed it before I switched from the 1.4.x branch back to the trunk
about two weeks ago.

Comment 3

[Felix Miata]

This bug now also applies to trunk, as of 2003120208 at least. A way to verify
without shutting down Moz is with a window resize:

To reproduce:
1-Open Moz
2-Open a new window
3-Resize the 2nd window
4-Close the 2nd window
5-Open another new window

Actual behavior:
3rd window opens at size and position of closed 2nd window

Expected behavior:
3rd window opens at size of 1st window in a position slightly offset from 1st
window position

Comment 4

[jhp (no longer active)]

Attachment: patch

This patch was checked in by Kaply into MOZILLA_1_4_BRANCH, but it was never
checked in to the trunk.  Kaply, is this what we want to take, or do we need to
make some changes for the trunk?

Comment 5

[Asa Dotzler [:asa]]

not going to block the release for this. We'd consider approving a reviewed patch.

Comment 6

[Felix Miata]

What do we need to get this patch already long ago on the 1.4.x branch into the
trunk? Is there some problem with it Mike? Is it simply waiting on Javier to
request review?

Comment 7

[Mike Kaply [:mkaply]]

I'm not sure if the branch patch will fix this on the trunk. I'm working on it.

Comment 8

[Mike Kaply [:mkaply]]

I saw this happen once on the trunk but couldn't recreate it again.

The scenario in this bug certainly doesn't fail on the trunk for me...

Comment 9

[Felix Miata]

Attachment: 1280x960 screenshot of comment 3 recreate

Happens to me every time. CZ is open, and mailnews has been opened. Smaller
window is browser window number 3, 4, 5 . . ., in size and position of closed
window #2. Last I checked, comment #0 is just as easy to recreate, last night
IIRC.

Comment 10

[Felix Miata]

Problem continues on the trunk.

Comment 11

[Felix Miata]

BTW, I wrote comment 10 after experiencing the same problem after replacing MCP
FP2 with eCS 1.1 (on 1 Jan.), so the likelihood of a system configuration issue
seems rather remote.

Comment 12

[Mike Kaply [:mkaply]]

OK, pertaining to comment 3, this is the way it works on Windows and the way (as
far as I know) it has always worked.

Do you think different?

Comment 13

[Felix Miata]

Mozilla 1.3 on Warp 4 FP12 (800x600) exhibits the behavior described as expected
behavior in comment 1 and comment 3. So does Mozilla 1.7b on Win98 (1024x768).

Comment 14

[Felix Miata]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4.2) Gecko/20040402 (1280x960) on
eCS 1.1 FP4 also exhibits the behavior described as expected behavior in comment
1 and comment 3. Current trunk still exhibits the behavior described as actual
behavior in comment 1 and comment 3.

Comment 15

[aaronr]

The window positions are stored by nsXULWindow::SavepersistentAttributes when
PAD_POSITION is dirty.  In this specific scenario, it should be getting called
by nsWebShellWindow::HandleEvent (when handling NS_GOTFOCUS).  OS/2 wasn't
behaving correctly because the frame window would never get a NS_GOTFOCUS.  This
is because a Windows frame will be treated as a nsWindow and therefore the
nsWindow handling of activation and focus will generate the appropriate
NS_GOTFOCUS, NS_LOSTFOCUS, etc. events.  In OS/2, the frame is a nsFrameWindow
and the message proc will resolve to be nsFrameWindow::FrameMessage.  There is
nothing in there to generate the needed NS_GOTFOCUS.

So I basically stole the NS_GOTFOCUS, NS_ACTIVATE, NS_DEACTIVATE, NS_LOSTFOCUS,
NS_PLUGIN_ACTIVATE code from nsWindow.cpp and placed it in nsFrameWindow.cpp.  I
don't know what kind of freaky behavior this might introduce, but it seems to me
that it should be minimal; this will behave more like Windows than it did before
and we are striving to emulate the Windows focus model.

Comment 16

[aaronr]

Attachment: fix attempt #1

This fix works for me.	I've done some minimal testing and don't see any side
effects.

Comment 17

[Mike Kaply [:mkaply]]

Attachment: Slimmed down fix

I tried to fix as little as possible so we potentially break as little as
possible.

Comment 18

[Mike Kaply [:mkaply]]

Fix checked in, slimmed down a little more.

Comment 19

[jhp (no longer active)]

Please post the final patch you checked in.

Comment 20

[Mike Kaply [:mkaply]]

Attachment: Final fix that was applied

All I added was the Dispatch of NS_GOTFOCUS

It fixed the problem and has the least likelihood of side effects