Closed Bug 222502 Opened 21 years ago Closed 20 years ago

last closed window position not remembered at restart

Categories

(Core :: XUL, defect)

1.4 Branch
x86
OS/2
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: mrmazda, Assigned: mkaply)

Details

(Keywords: fixed1.7)

Attachments

(3 files, 2 obsolete files)

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.
Mike, was this fixed under another bug, or was the patch never checked in?
Something fixed it before I switched from the 1.4.x branch back to the trunk
about two weeks ago.
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
Attached patch patchSplinter Review
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?
Flags: blocking1.6?
not going to block the release for this. We'd consider approving a reviewed patch.
Flags: blocking1.6? → blocking1.6-
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?
I'm not sure if the branch patch will fix this on the trunk. I'm working on it.
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...
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.
Problem continues on the trunk.
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.
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?
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).
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.
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.
Attached patch fix attempt #1 (obsolete) — Splinter Review
This fix works for me.	I've done some minimal testing and don't see any side
effects.
Attached patch Slimmed down fix (obsolete) — Splinter Review
I tried to fix as little as possible so we potentially break as little as
possible.
Attachment #146526 - Attachment is obsolete: true
Fix checked in, slimmed down a little more.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Please post the final patch you checked in.
All I added was the Dispatch of NS_GOTFOCUS

It fixed the problem and has the least likelihood of side effects
Attachment #146621 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: