1915573 - pge.com - the login page renders nearly blank some of the time (with login form missing)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 129.0.2 (release)

Preconditions:

• ETP set to STRICT
• Clean profile

Steps to reproduce:

1. Navigate to: https://m.pge.com/#dashboard
2. Observe

Expected Behavior:
The login page and forms are loading

Actual Behavior:
Blank page

Notes:

• Not reproducible with ETP STANDARD/turned OFF (both Normal and Private Browsing)
• Reproducible on the latest Nightly

---

Created from webcompat-user-report:c2977072-46d2-4f1c-94df-aeae8f1e0c56

Comment 1

[Daniel Holbert [:dholbert]]

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:

<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.)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast showing bug intermittently reproducing (regardless of ETP status)

Here's a screencast of me trying to load/reload https://m.pge.com 8 times in a fresh profile. Here are the results of each attempt in the video -- tl;dr it was "good" 3 times and "bad" 5 times, and ETP doesn't matter.
Trial results:
(1) bad
(2) bad
(3) good
(4) bad
[At this point in the screencast, I toggle the UI to turn off ETP for this site.]
(5) good
(6) bad
(7) bad
(8) good

Comment 3

[Daniel Holbert [:dholbert]]

PG&E is apparently also about to launch a redesign of their website ( some details on https://pge.com/en/featured/new-pge-account.html -- and based on an email I received as an account-holder, Nov 11th is some sort of deadline/cut-over date). So it's probably not worth digging into this much further until after that redesign ships. (More than likely, this issue won't be reproducible at that point; and maybe we'll have new issues to look into.)

Comment 4

[Dennis Schubert [:denschub]]

Let's set webcompat:blocked for now, and re-check this in November.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

PG&E is apparently also about to launch a redesign of their website ( some details on https://pge.com/en/featured/new-pge-account.html -- and based on an email I received as an account-holder, Nov 11th is some sort of deadline/cut-over date). So it's probably not worth digging into this much further until after that redesign ships

Update: it looks like their redesign is pushed out to "Spring 2025" based on updated content on https://pge.com/en/featured/new-pge-account.html

In light of that, this probably is back to the worth-spending-time-to-investigate category.

(I can reproduce this locally on linux in a fresh Firefox profile, with Firefox release as well as Nightly.)

Comment 6

[Dennis Schubert [:denschub]]

I see an exception about an undefined function. But if I disable ETP, the login page loads for me. Do you see the same, Daniel? I wonder if ETP is just overly enthusiastic and blocking something critical.

Comment 7

[Dennis Schubert [:denschub]]

This might also be something else. It doesn't load on the first load for me, but it works on the next one. Clearing caches doesn't break it, but clearing Cookies does break it.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

For me when the page loads properly I see one request to:
https://m.pge.com/resources/js/com.mobileweb.common.js?ver=1734470186453

When it's broken I see two requests to that URL

Comment 9

[Jeff Muizelaar [:jrmuizel]]

It could be that OneTrust Cookie Auto-Blocking is screwing things up

Comment 10

[Jeff Muizelaar [:jrmuizel]]

This site uses require.js for loading modules and it seems like it's getting stuck sometimes.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I think we get in a bad spot when we fire the load event for https://m.pge.com/resources/js/com.mobileweb.common.js without executing the script.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

I think this might be caused by the beforescriptexecute event.

From OtAutoBlock.js:

        a.addEventListener(
          'beforescriptexecute',
          c = function (e) {
            'text/plain' ===
            a.getAttribute('type') &&
            e.preventDefault();
            a.removeEventListener('beforescriptexecute', c)
          }
        )

Comment 13

[Jeff Muizelaar [:jrmuizel]]

If I disable dispatching beforescriptexecute I wasn't able to reproduce the problem after a bunch tries.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

https://github.com/pressidium/pressidium-cookie-consent/blob/de9983548184a916ebd28d8b38d240ba14e17adc/src/client/block-scripts.js#L70 suggests that we might have different behaviour around script blocking using MutationObserver than Chrome and Safari do.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Here's another similar thing: https://github.com/ScriptedAlchemy/yett/blob/0d244ec739911f14e1865d64eb4f66eb3239f80f/src/observer.js#L20

Comment 17

[duc]

Login page shows up completely blank for me, FF 139.1.

User Agent Switcher to Edge does not work... Is there a site-specific setting for beforescriptexecute?

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to duc from comment #17)

Login page shows up completely blank for me, FF 139.1.

Interesting -- thanks for letting us know. Could you see if you can reproduce in a fresh Firefox profile?

I just retested and personally I can't reproduce anymore (whereas I could previously, per comment 2). I just tried loading & reloading & shift+reloading these URLs a bunch of times:
https://m.pge.com/#dashboard
https://m.pge.com/

I tested Nightly 141 and release 139.0.1 in a fresh profile with ETP Standard, and retested with ETP Strict just in case that was relevant (per comment 0). I reloaded the page >10 times in each tested version/config. I didn't ever see any blank pages.

Raul, can you still reproduce?

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to duc from comment #17)

Is there a site-specific setting for beforescriptexecute?

(Not that I'm aware of. Bug 1584269 is filed on removing it entirely though.)

Comment 20

[Daniel Holbert [:dholbert]]

Quoting duc from bug 1898899 comment #23, which I suspect is meant as a followup to comment 17 here:

I created a new profile on the Developer Edition, and pge.com works like it does on Edge. How do I go about fixing my actual profile?

That's great news!

I don't think we ever really fully understood what was going on here, so there aren't any for-sure suggestions here. But two things you might try:
(1) Try clearing cookies and site data for pge.com by following https://support.mozilla.org/en-US/kb/clear-cookies-and-site-data-firefox while you're viewing pge.com.

(2) If you've got any extensions installed (particularly ones that might block content), you might try turning those off and see if it helps.

If either of those help, please let us know, since it might be useful diagnostic info. If they don't help, I don't have other great suggestions at the moment, but it's nonetheless good to know that a fresh profile addresses the issue you were seeing.

Comment 21

[Raul Bucata]

As per comment 18, I am not able to reproduce the issue. The login page is rendered, as expected, using the latest Nightly, regardless of the ETP status.

Comment 22

[Daniel Holbert [:dholbert]]

duc, could you test again? Note that pg&e just deployed a major site refresh over the weekend, so it's likely that the issue you were hitting last week is no longer present.

Comment 23

[Daniel Holbert [:dholbert]]

Closing as WFM since this seemed to only affect one Firefox profile on one user's machine, and (pending a response to comment 20-22 from the reporter) it's likely fixed there as well now, given the site was redesigned.