The user preference "browser.screen_resolution" is ignored, because it is read before the user's prefs file has been read in. "browser.screen_resolution" is read in nsDeviceContextMac.cpp, which is called for the first window that is created. That is the hidden window, which gets created when the nsAppShellService is initialized. However, this all happens before ReadUserPrefs() is called, because we have to initialize the nsAppShellService() to be able to do profile stuff. So there's an ordering problem here on startup that needs fixing. I have no idea who should get this bug, or what the correct fix is. So I'm giving it to danm. Perhaps the hidden window should be created later?

The correct fix is to register a listener on the pref and when it changes, update your variable. Minor details would be forcing all the window to redraw to reflect the change. It shouldn't just be a startup issue as we might want to provide UI switch to allow the user to change during runtime. My 2.5 cents.

David's comment is right on. That is the standard for using prefs - grab it each time it's used or register a callback and update your cached value when it changes.

mass-moving most m11 bugs to m12

Mass-moving non-PDT+ bugs to M13

preferences plumbing, then. gramps sez mcafee will find a caring home for this one.

sounds easy, m13.

spam: added self to cc list as this might affect my realm.

m15

Move to M16 for now ...

Move to M21 target milestone.

nav triage team: We would like to get this fixed, but lower priority. Nsbeta1, p4, reassign to pchen

nav triage: not a nsCatFood issue for common usage. Moving to Future. if you want to renominate this bug for catFood, please explain the user impact clearly and the frequency, severity and percentage of users it would impact.

Changing platform

xp...

Shouldn't this be a per-machine pref rather than a per-user pref? (and even further, a per-X-server pref, on Linux?) I don't see why two users would have two different resolutions on the same computer... That seems contradictory to me.

-> default assignee

->ben

not an XPApps bug

Reassigning to Don

> I don't see why two users would have two different resolutions "startx" with different arguments, leading to different X resolutions. That said, I assume this is still an issue. Is some mac person willing to own this?

Wow, this is old :)

I'm closing this as WONTFIX (really as MOOT) because the string "screen_resolution" is no longer anywhere to be found in the source tree (except one e4x test case that is just using a prefs dump as a big XML file). If there is still a problem with screen resolution adjustment however that's done now, please file a new bug.

the pref was renamed to layout.css.dpi

Ah. Do you disagree with closing the bug?

no, because the code to read the pref was entirely rewritten and I believe it works now