Bugzilla

I hit this same issue **regardless of ETP status** -- I hit this in a fresh profile, and even with ETP turned off for this site.  The page occasionally loads the login form, but usually it's mostly-blank (aside from a dialog and a footer).  I'm using Firefox 133.0a1 (2024-10-11) (64-bit) Nightly on Ubuntu 24.10 on a gigabit ISP connection in the SF bay area, if any of that ends up mattering.
--> Moving back to Site Reports and out of the Privacy category.

In my regular user-profile, things are usually "good" for some reason; whereas in a fresh user-profile, things are usually "bad" (blank). I suspect there's a race condition involved here, and various bits of overhead in my regular user-profile might be saving me somehow (whether resource contention among tabs, or something in my cache, or addons that do stuff on pageload and slow something down just enough or blocking some resource that's involved causing the problem).

For completeness I'll mention that in bad cases, the rendering isn't *quite* blank -- I always get a "your browser is unsupported" dialog floating in the middle of the page (see bug 1898899 and particularly bug 1898899 comment 3 and 5 on that) as well as a cookie-info footer. I can dismiss the former, but it comes back on reload. I can dismiss the latter and it stays dismissed on reload.  Aside from those two things, the page is blank when the bug happens.

This is mostly-not-at-all-reproducible in Chrome, but I was able to trigger what looks like this bug once or twice there, when I was poking in the debugger and single-stepping through whole-document DOM modifications (possibly putting Chrome on the bad side of whatever the race condition is)

Looking at the DOM in devtools for a "bad" load, the issue is that a bunch of the DOM is indeed empty.   e.g. the `body` has this chain of descendants near its first few children:
```html
<div class="pge_coc-common-container">
  <div class="row">
    <div id="header" class="col-lg-12" role="navigation"></div>
```

This #header element is empty in a bad load (as shown there^), but it's nonempty in a "good" load.

I tried to capture that element getting populated in Chrome by triggering a breakpoint when it was empty and then toggling "Break on: subtree modifications" (and "Break on: node removal" in case the node is getting swapped out), but for whatever reason, those "break on" requests don't actually fire when that element gets populated-with-children.  Too bad.

I caught this in the Firefox profiler, though -- both a "good" and a "bad" load, in the same browsing session (using a fresh user-profile).
GOOD: https://share.firefox.dev/3NkmFFv
BAD: https://share.firefox.dev/3zLVL6h
(note that the "bad" profile's screenshots do show the "good" rendering at the very start; that's the point where I reloaded and ended up bad, which is what the rest of the profile shows)

I suspect this might be a good use-case for the JS tracer (capturing a trace of "good" and of "bad" and comparing them).  I'm not yet used to that tool though, so I haven't done that; if anyone else can repro and is interested in doing that, it might be the best way to push this forward.

I hit this same issue **regardless of ETP status** -- I hit this in a fresh profile, and even with ETP turned off for this site.  The page occasionally loads the login form, but usually it's mostly-blank (aside from a dialog and a footer).  I'm using Firefox 133.0a1 (2024-10-11) (64-bit) Nightly on Ubuntu 24.10 on a gigabit ISP connection in the SF bay area, if any of that ends up mattering.
--> Moving back to Site Reports and out of the Privacy category.

In my regular user-profile, things are usually "good" for some reason; whereas in a fresh user-profile, things are usually "bad" (blank). I suspect there's a race condition involved here, and various bits of overhead in my regular user-profile might be saving me somehow (whether resource contention among tabs, or something in my cache, or addons that do stuff on pageload and slow something down just enough or blocking some resource that's involved causing the problem).

For completeness I'll mention that in bad cases, the rendering isn't *quite* blank -- I always get a "your browser is unsupported" dialog floating in the middle of the page (see bug 1898899 and particularly bug 1898899 comment 3 and 5 on that) as well as a cookie-info footer. I can dismiss the former, but it comes back on reload. I can dismiss the latter and it stays dismissed on reload.  Aside from those two things, the page is blank when the bug happens.

This is mostly-not-at-all-reproducible in Chrome, but I was able to trigger what looks like this bug once or twice there, when I was poking in the debugger and single-stepping through whole-document DOM modifications (possibly putting Chrome on the bad side of whatever the race condition is)

Looking at the DOM in devtools for a "bad" load, the issue is that a bunch of the DOM is indeed empty.   e.g. the `body` has this chain of descendants near its first few children:
```html
<div class="pge_coc-common-container">
  <div class="row">
    <div id="header" class="col-lg-12" role="navigation"></div>
```

This #header element is empty in a bad load (as shown there^), but it's nonempty in a "good" load.

I tried to capture that element getting populated in Chrome by triggering a breakpoint when it was empty and then toggling "Break on: subtree modifications" (and "Break on: node removal" in case the node is getting swapped out), but for whatever reason, those "break on" requests don't actually fire when that element gets populated-with-children.  Too bad.

I caught this in the Firefox profiler, though -- both a "good" and a "bad" load, in the same browsing session (using a fresh user-profile).
GOOD: https://share.firefox.dev/3NkmFFv
BAD: https://share.firefox.dev/3zLVL6h
(note that the "bad" profile's screenshots do show the "good" rendering at the very start; that's the point where I reloaded and ended up bad, which is what the rest of the profile shows)

I suspect this might be a good use-case for the JS tracer (capturing a trace of "good" and of "bad" and comparing them).  I'm not yet used to that tool though, so I haven't done that; if anyone else can repro and is interested in doing that, it might be the best way to push this forward.  (We might be able to figure out what's going on from comparing the above performance-profiles, too, but I haven't gone too far into that yet.)