Preferences window is badly placed with new copy of Camino but old user

RESOLVED FIXED in Camino1.0

Status

--
minor
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: froodian, Assigned: sfraser_bugs)

Tracking

({fixed1.8, polish})

unspecified
Camino1.0
PowerPC
Mac OS X
fixed1.8, polish

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

This bug is so odd it doesn't even seem possible, but I experience it every time
I download a new nightly of Camino.

When opening a build of Camino for the first time, the preferences window is low
enough on the screen that the tallest pane (Privacy) gets partially hidden
behind the dock.  

This doesn't happen with a fresh user.

Reproducible: Always

Steps to Reproduce:
1. Download most recent nightly of Camino.
2. Open new nightly.
3. Command-, (or Camino->Preferences)

Actual Results:  
Window is too low.
Are we somehow erasing this pref because of the new identifier?

Reporter: Do you see this on *every* new nightly or just 1.0a1?
(Assignee)

Comment 2

13 years ago
Prefs window placement bugs me too; for me, it goes back to the top of the
screen all the time.
Assignee: pinkerton → sfraser_bugs
Severity: trivial → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.0
In my case, it occasionally moves from the top left corner to midway down the
left edge of my screen.  I haven't seen it happen in a while, but it seems to
occur for a string of nightlies when it does.
(Reporter)

Comment 4

13 years ago
(In reply to comment #1)
> Are we somehow erasing this pref because of the new identifier?
> 
> Reporter: Do you see this on *every* new nightly or just 1.0a1?

It seems the behavior is linked to a "Camino" user-agent spoof (.84?).  As an
independant CamiOptions bug, Turning *off* user-agent spoofing is a bit odd, so
I never realized I still had the string in my prefs.js

So what happens is when I have the .84 user-agent, the preferences window drifts
odd in a somewhat downward direction, causing the problem described.

When I remove the user-spoof though, the preferences window drifts upwards upon
each launch until it hits the menubar, when the OS doesn't allow it to drift
further.

I see this irregardless of build back at least to Sep 1.
(Assignee)

Comment 5

13 years ago
I have no idea why the user-agent would have any effect on the prefs window
location saving.

I think the window drifts because the saved size doesn't match the new size
(since you've likely moved to a different panel with a different height), and,
since Cocoa coords are upside-down, it keeps the window bottom rather than the
window top.
Status: NEW → ASSIGNED

Comment 6

13 years ago
Simon's exactly right. I can think of two solutions:

1) Remember the last accessed prefpane, so our size matches, or
2) Save the top-left coords instead (simple arithmetic).

Transmit (as an example) does solution 2.
Keywords: polish
not bad enough to hold for
Target Milestone: Camino1.0 → Camino1.1
(Assignee)

Comment 8

13 years ago
Fixed by storing the top-left point (and centering it on first run).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Target Milestone: Camino1.1 → Camino1.0
You need to log in before you can comment on or make changes to this bug.