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?
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.
(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.
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
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.
not bad enough to hold for
Target Milestone: Camino1.0 → Camino1.1
Fixed by storing the top-left point (and centering it on first run).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: Camino1.1 → Camino1.0
You need to log in before you can comment on or make changes to this bug.