Open Bug 2008115 Opened 3 months ago Updated 1 month ago

pge.com - shows modal popup for Firefox users: "Your current browser may not give you the best experience."

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Type:
defect

Tracking

(Webcompat Priority:P3, Webcompat Score:1)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P3
Webcompat Score 1

People

(Reporter: dholbert, Assigned: twisniewski)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: leave-open, webcompat:site-report, webcompat:sitepatch-applied)

User Story

user-impact-score:0
platform:windows,mac,linux,android
impact:unsupported-warning
configuration:general
affects:all
branch:release
diagnosis-team:webcompat

Attachments

(4 files)

screenshot
872.71 KB, image/png
Details
DOM snippet for the browser-not-supported modal popup
1.23 KB, text/plain
Details
JS snippet that injects the modal
1.51 KB, text/plain
Details
Bug 2008115 - add a CSS webcompat intervention for pge.com; r?ksenia
48 bytes, text/x-phabricator-request
Details | Review
Attached image screenshot —

PG&E is warning Firefox users that their browser is unsupported again (as they were previously in bug 1898899, though they seemed to stop for a while).

See attached screenshot.

STR:

  1. Start Firefox with a fresh profile (or clear cookies)
  2. Visit https://www.pge.com/
  3. Wait a second or two after pageload.

ACTUAL RESULTS:
This modal popup appears:

Your current browser may not give you the best experience.

We test our site on the browser versions used by 97% of our customers. It doesn’t look like the one you’re using has been tested. Please use a browser listed at pge.com/browsers.
The user has to click an X at the top right of this dialog in order to proceed to use the site.

EXPECTED RESULTS:
No such modal popup.

I can reproduce in current release 146.0 (64-bit) on Ubuntu Linux, Win11, and macOS Tahoe.
I can also reproduce in Nightly 148.0a1 (only tested on Ubuntu, but I assume all platforms are affected).

Here's the DOM snippet (which is a direct child of the page's <body> element), copypasted from devtools, for reference.

Here's the JS snippet that injects the modal (based on doing a ctrl+shift+f in devtools debugger for "current browser")

This is identified as "source126" (with some random 3-digit number) so I think it's a bit of dynamically injected JS rather than a script that's available at some public URL.

The Chrome Mask extension (activated for https://www.pge.com/) does not help here, but the "User Agent Switcher" extension does help (spoofing as Chrome 143 on Windows).

So this appears to be UA-sniffing, but it might be done on a script or iframe that's got a different origin from www.pge.com.

User Story: (updated)
Webcompat Score: --- → 1
Severity: -- → S3
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: 1 → 6
Keywords: webcompat:needs-diagnosis, webcompat:site-report
Priority: -- → P2
Webcompat Score: 6 → 5

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

The Chrome Mask extension (activated for https://www.pge.com/) does not help here, but the "User Agent Switcher" extension does help (spoofing as Chrome 143 on Windows).

So this appears to be UA-sniffing, but it might be done on a script or iframe that's got a different origin from www.pge.com.

Update -- it's not an iframe, but rather a POST to a server on a different domain, which returns back an action to take, which in part is dependent on the user-agent that gets sent with that request.

It's a POST to this URL:
https://pge.tt.omtrdc.net/rest/v1/delivery?client=pge&sessionId=d7504161420b42eb814c55361ebfc7bc&version=2.11.7

DevTools show that the POST request to that domain gives a JSON response with this as part of the JSON:

{
	"execute": {
		"pageLoad": {
			"options": [
				{
					"content": [
						{
							"type": "customCode",
							"selector": "HEAD",
							"cssSelector": "",
							"content": "<script>\nsetTimeout(function(){ \n    document.getElementsByTagName(\"body\")[0].insertAdjacentHTML(\"afterend\",\n    '<div id=\"targetModal\" class=\"modal\" style=\"display:none;position:fixed;z-index:999999;padding-top:150px;left:0;top:0;width:100%;height:100%;overflow:auto;background-color: rgb(0,0,0);background-color: rgba(0,0,0,0.4);\"><div class=\"modal-content\" style=\"  position: relative;background-color: #fefefe;margin: auto;padding: 0;border: 1px solid #888; width: 80%;box-shadow: 0 4px 8px 0 rgba(0,0,0,0.2),0 6px 20px 0 rgba(0,0,0,0.19);\"><div class=\"modal-header\" style=\"padding: 2px 16px;color:#000;\"><span id=\"targetModalClose\" class=\"close\" style=\"float: right;font-size: 28px;font-weight: bold;cursor: pointer;\">&times;</span></div><div class=\"modal-body cmp-text\" style=\"padding:20px;color:#1b1c1d;\"><h5>Your current browser may not give you the best experience.</h5><br/><p> We test our site on the browser versions used by 97% of our customers. It doesn’t look like the one you’re using has been tested. Please use a browser listed at <a id=\"browsers\" target=\"_blank\" href=\"https://www.pge.com/browsers\">pge.com/browsers</a>.</p><br/></div></div></div>');        \n    var modal = document.getElementById(\"targetModal\");\n    modal.style.display = \"block\";\n    var span = document.getElementById(\"targetModalClose\");\n    span.onclick = function() {\n      modal.style.display = \"none\";\n    }\n    window.onclick = function(event) {\n      if (event.target == modal) {\n        modal.style.display = \"none\";\n      }\n    }\n},1000);\n</script>"
						}
					],
					"type": "actions",
					"responseTokens": {
						"activity.id": "310983",
						"experience.id": "0",
						"experience.name": "Experience A",
						"activity.name": "PGE.COM: Unsupported Browser (Firefox) - 2025.12 - AA"
					},
					"sourceType": "target"
				}
			]
		}
	}
}

And then that <script> element gets inserted into the DOM and results in this popup.

If I manually visit https://pge.tt.omtrdc.net/ and activate Chrome Mask on that domain, then on my next visit to pge.com, my response for that POST request instead just has this -- no special actions to execute, no special named "Experience"

{
	"execute": {
		"pageLoad": {}
	}
}

So: we could sitepatch this by shipping a UA override for pge.tt.omtrdc.net, I think.

Keywords: webcompat:needs-diagnosis → webcompat:needs-sitepatch

Good find, Dan. But for now, let's ship a CSS intervention to hide the banner and see what happens.

Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED

Reverted this because it was causing mochitests failures in browser_aboutcompat.js.

  • Revert link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | browser/extensions/webcompat/tests/browser/browser_aboutcompat.js | test_about_compat_loads_properly - Uncaught exception in test - interventions are listed - timed out after 50 tries.
Flags: needinfo?(twisniewski)

This was caused by the patch in bug 2016730.

Flags: needinfo?(twisniewski)
User Story: (updated)
Webcompat Priority: P2 → P3
Webcompat Score: 5 → 1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: