Bug 1856637 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that reaches into our `WindowProc`;
- but our handling of window messages (`WM_NCPAINT` and `WM_SETTINGCHANGE`) assumes that `gfxVars::Initialize()` has necessarily already been called, thus we crash as we dereference `gfxVars::sInstance.mRawPtr`.
Revision 1 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that reaches into our `WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we crash as we dereference `gfxVars::sInstance.mRawPtr`.
Revision 2 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that reaches into our `WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we can crash as we dereference `gfxVars::sInstance.mRawPtr` if some specific messages were queued.
Revision 3 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that reaches into our `WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we can crash as we dereference `gfxVars::sInstance.mRawPtr` if some specific window messages were queued.
Revision 4 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that can reach into our `WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we can crash as we dereference `gfxVars::sInstance.mRawPtr` if some specific window messages were queued.
Revision 5 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that can reach into our `WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we can crash as we dereference `gfxVars::sInstance.mRawPtr` if these specific window messages were queued.
Revision 6 by
on 
After looking at more stack data, this occurs more precisely while `nsBrowserGlue` is observing `app-startup`, and we reach `nsWindowWatcher::OpenWindow`. This [thus](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1234-1236) seems to point to [the following call](https://searchfox.org/mozilla-central/source/browser/components/BrowserGlue.sys.mjs#1630-1636) in `_earlyBlankFirstPaint`:

```javascript
    let win = Services.ww.openWindow(
      null,
      "about:blank",
      null,
      browserWindowFeatures,
      null
    );
```

So I think the crash can be summarized as follows:
-  `gfxVars::Initialize()` is called as part of `nsXREDirProvider::DoStartup()`;
- `nsBrowserGlue` observes `app-startup` *before* that call, and that can reach into our `nsWindow::WindowProc`;
- but our handling of window messages `WM_NCPAINT` and `WM_SETTINGCHANGE` assumes that `gfxVars::Initialize()` has necessarily already been called, thus we can crash as we dereference `gfxVars::sInstance.mRawPtr` if these specific window messages were queued.

Back to Bug 1856637 Comment 1