[Mach-O]Window position not remembered if flush with left edge of screen

RESOLVED FIXED in mozilla1.3final

Status

()

defect
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: devsin, Assigned: danm.moz)

Tracking

Trunk
mozilla1.3final
PowerPC
macOS
Points:
---
Bug Flags:
blocking1.3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3] fixed1.3)

Attachments

(1 attachment)

Reporter

Description

17 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210

If windows are manually resized and positioned flush with the left edge of the
display, when Mozilla is restarted, the horizontal position will be offset (many
pixels to the right). Other browsers don't do this. You suck! :P

Reproducible: Always

Steps to Reproduce:
1. Launch Mozilla with a clean (new) profile
2. Click the maximize widget to resize the browser window
3. Manually resize the browser window (to appropriate dimesions) *without*
changing position
4. Quit and re-launch Mozilla
Actual Results:  
When the browser starts up, the window will be the correct size, but will have
shifted about an inch to the right. You have to manually re-position the window
to be flush with the left edge of the screen every time you start Mozilla.

Expected Results:  
Mozilla should correctly remember both the browser window size AND position.

This is a Mach-O only issue (it didn't affect CFM builds). I think this issue
did occur in the CFM build in ancient times (and was fixed), if somebody wants
to go hunting for the old report. This should hold back 1.3 final (it's very
annoying and there's no work-around).
Reporter

Comment 1

17 years ago
Setting the blocking1.3? flag. This issue was also present in earlier (nightly)
Mach-O builds (prolly always been there). Fix me, fix me! (Apparently, the
Bugzilla helper doesn't let you set keywords or flags. Who'da thunk it?)
Flags: blocking1.3?
Flags: blocking1.3? → blocking1.3+
Summary: Window position not remembered if flush with left edge of screen → [Mach-O]Window position not remembered if flush with left edge of screen

Comment 2

17 years ago
-> Jan
Assignee: jaggernaut → varga

Updated

17 years ago
Keywords: nsbeta1

Comment 3

17 years ago
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
Assignee

Comment 4

17 years ago
gimme
Assignee: varga → danm
Target Milestone: --- → mozilla1.3final
Assignee

Comment 5

17 years ago
We stop saving window position to persistent store when a window is zoomed to
the Standard state. So following the steps to reproduce exactly, in step 4
Mozilla's first window is opened to its new size but in the same position as
before it was zoomed.

However there's another bug. The hardwired window border constants in
nsMacWindow are incorrect for standard OSX windows, and the fix for bug 162090
and bug 162029 prevents new windows from being positioned even partly
off-screen. These two things prevent new windows from opening less than four
pixels from the left edge.

So this patch saves the window's position just as it's coming back to the User
state. It also calculates the window border widths using the nifty new OS8.5+
APIs. Last, it junks nsMacWindow::mIsDialog; a member variable related to this
whole mess whose value was never anything but false.
Assignee

Updated

17 years ago
Attachment #114840 - Flags: superreview?(sfraser)
Attachment #114840 - Flags: review?(pinkerton)
Attachment #114840 - Flags: superreview?(sfraser) → superreview+
Comment on attachment 114840 [details] [diff] [review]
persist user state position and softwire OSX window positioning

r=pink
Attachment #114840 - Flags: review?(pinkerton) → review+
Assignee

Updated

17 years ago
Attachment #114840 - Flags: approval1.3?

Comment 7

17 years ago
Comment on attachment 114840 [details] [diff] [review]
persist user state position and softwire OSX window positioning

a=asa (on behalf of drivers) for checkin to 1.3
Attachment #114840 - Flags: approval1.3? → approval1.3+
Assignee

Comment 8

17 years ago
.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
Does this have ramifications for bug 181687?

Updated

17 years ago
Whiteboard: [adt3] → [adt3] fixed1.3
You need to log in before you can comment on or make changes to this bug.