Closed Bug 667183 Opened 15 years ago Closed 15 years ago

Create a static nsGlobalWindow::Init method to do all one-shot initializations currently in nsGlobalWindow ctor

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: mounir, Assigned: mounir)

References

Details

Attachments

(1 file, 1 obsolete file)

No description provided.
Summary: Create a static nsGlobolWindow::Init method to do all one-shot initializations currently ins nsGlobalWindow ctor → Create a static nsGlobolWindow::Init method to do all one-shot initializations currently in nsGlobalWindow ctor
Attached patch Patch v1 (obsolete) — — Splinter Review
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #541925 - Flags: review?(jst)
Whiteboard: [needs review]
Flags: in-testsuite-
I realize some things, especially related to Preferences might not work as expected. I don't know for ::Add*VarCache but ::GetCString() might always return the default value because user pref will not be read yet.
Comment on attachment 541925 [details] [diff] [review] Patch v1 r=jst, but please do make sure that the preference values do get read correctly this early in startup (or that the value gets updated once the value is available).
Attachment #541925 - Flags: review?(jst) → review+
Summary: Create a static nsGlobolWindow::Init method to do all one-shot initializations currently in nsGlobalWindow ctor → Create a static nsGlobalWindow::Init method to do all one-shot initializations currently in nsGlobalWindow ctor
Once you land this, the null-check you added to the DOM memory reporter can get backed out, right?
(In reply to Boris Zbarsky (:bz) from comment #4) > Once you land this, the null-check you added to the DOM memory reporter can > get backed out, right? If there is no weird situations where about:memory is loaded after ::Shutdown(), yes.
Attached patch Patch v1.1 — — Splinter Review
With all preferences check staying in the ctor.
Attachment #541925 - Attachment is obsolete: true
Whiteboard: [needs review] → [inbound]
Backed out because of build failures on inbound. https://hg.mozilla.org/integration/mozilla-inbound/rev/902d3de6f41d
Whiteboard: [inbound]
Comment on attachment 557022 [details] [diff] [review] Patch v1.1 >+ // There are two reasons to have Init() failing: if we were not able to >+ // alloc the memory or if the size we want to init is too high. None of them >+ // should happen. >+ NS_ASSERTION(sWindowsById->Init(), "Init() should not fail!"); Are you seriously only calling Init in debug builds?
(In reply to Ms2ger from comment #8) > Comment on attachment 557022 [details] [diff] [review] > Patch v1.1 > > >+ // There are two reasons to have Init() failing: if we were not able to > >+ // alloc the memory or if the size we want to init is too high. None of them > >+ // should happen. > >+ NS_ASSERTION(sWindowsById->Init(), "Init() should not fail!"); > > Are you seriously only calling Init in debug builds? Oooouuuups :) Fixed patch sent to try.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
This broke DOMWINDOW printfs because you removed the --gRefCnt.
Pushed by clegnitto@mozilla.com: https://hg.mozilla.org/releases/mozilla-release/rev/0432fe833c93 Create a static nsGlobalWindow::Init method to do one-shot initializations currently in nsGlobalWindow ctor. r=jst
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: