Open Bug 1939466 Opened 2 months ago Updated 3 hours ago

vodafone.it - The page fails to load

Categories

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

Firefox 133
Desktop
All

Tracking

(Webcompat Score:9, Webcompat Priority:P1, firefox133 affected, firefox134 affected, firefox135 affected)

ASSIGNED
Webcompat Score 9
Webcompat Priority P1
Tracking Status
firefox133 --- affected
firefox134 --- affected
firefox135 --- affected

People

(Reporter: rbucata, Assigned: twisniewski)

References

(Depends on 1 open bug, )

Details

(Keywords: webcompat:platform-bug, webcompat:site-report, webcompat:sitepatch-applied, Whiteboard: [webcompat-source:web-bugs][webcompat:sightline])

User Story

platform:windows,mac,linux,android
impact:workflow-broken
configuration:general
affects:all
branch:release
diagnosis-team:webcompat
user-impact-score:1600

Attachments

(1 file)

Environment:
Operating system: debian 12
Firefox version: 133.0

Steps to reproduce:

  1. Navigate to: https://www.vodafone.it/eshop/contenuti/rete-vodafone/copertura-mobile-5g.html
  2. Observe

Expected Behavior:
The page loads

Actual Behavior:
"No right to access page!" error message

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in firefox-nightly, and firefox-release
  • Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145713

Summary: vodafone.it - copertura mobile 5G → vodafone.it - The page fails to load
OS: Unspecified → All
Hardware: Unspecified → Desktop
Version: unspecified → Firefox 133

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Whiteboard: [webcompat-source:web-bugs] → [webcompat-source:web-bugs][webcompat:sightline]
Severity: -- → S2
User Story: (updated)
Priority: -- → P2

I can repro in Firefox Nightly; can't repro in Chrome. User-agent spoofing doesn't help.

There's a cookie overlay on first load, but you can still the bug reproducing behind the cookie banner.

Here's a profile of me loading the page for the first time, and then accepting cookies to dismiss the overlay, and then reloading and seeing the bug again: https://share.firefox.dev/40qbeDl

The page starts to properly-render for a little bit, and you can see a map, and then all of a sudden the page gets replaced with the " No right to access page! " message.

Not sure if this is the key thing or not, but network-devtools does show one network request that fails in Firefox vs. succeeds in Chrome:
https://geamaps.dsl.vodafone.it/gea190_v4/dwr/call/plaincall/WhitelistDomainsServiceFacade.areAllAncestorsDomainInWhitelist.dwr

In Chrome, that request (sent as an XHR) succeeds with status 200.

In Firefox, that request shows up in Network DevTools as having failed (red-circle-with-a-slash), with NS_BINDING_ABORTED in the "Transferred" column, and it's immediately followed by a request to https://geamaps.dsl.vodafone.it/gea190_v4/web/gea_forbidden.html which seems to be the actual URL that shows the "no right to access page" message.

I'm not sure if that request's failure is what causes the issue vs. if it's a side effect of the issue (e.g. the site decides to reject us elsewhere and cancels its in-flight XHR requests or something). But that's one string we could pull on here.

--> Kicking over to the networking team as a first-guess at folk who could diagnose further.

User Story: (updated)

I don't think that network request is the root cause (I've seen it succeed in Firefox and the page still showing "No right to access page"), I think it is cancelled because the iframe that requests it is navigated. Here's what I found so far:

--> switching back to the webcompat team for diagnosis

User Story: (updated)

The iframe navigation is done by this function in https://geamaps.dsl.vodafone.it/gea190_v4/web/js/gea.js?version=6.4:

function checkWhitelist(locations) {

	WhitelistDomainsServiceFacade.areAllAncestorsDomainInWhitelist(locations,
		function(isWhitelisted) {
			if(!isWhitelisted) {
				window.location.href = "gea_forbidden.html";
			}
	});
}

When I break in the inner callback function I see in the stack that it is called after receiving the response for https://geamaps.dsl.vodafone.it/gea190_v4/dwr/call/plaincall/WhitelistDomainsServiceFacade.areAllAncestorsDomainInWhitelist.dwr
The response for that request contains dwr.engine.remote.handleCallback("1","0",false); on Firefox but dwr.engine.remote.handleCallback("1","0",true); on Chrome (note the boolean at the end is different).
The request payload on Firefox and Chrome look the same except for the c0-e1 parameter - on Firefox its value is string:https%3A%2F%2Fgeamaps.dsl.vodafone.it but on Chrome it is string:https%3A%2F%2Fwww.vodafone.it.
Note that geamaps.dsl.vodafone.it (what Firefox sends) is the domain of the iframe whereas www.vodafone.it (what Chrome sends) is the domain of the page.

This function in https://geamaps.dsl.vodafone.it/gea190_v4/web/js/gea.js?version=6.4 is responsible for getting the origin:

function getAncestorOrigins() {
	var isFirefox = typeof InstallTrigger !== 'undefined';
	const urls = [];

	if (!isFirefox && location.ancestorOrigins !== undefined) {
		if(location.ancestorOrigins.length > 0) {
	  		return [...location.ancestorOrigins];
		} else {
			return [location.origin];
		}
	} else {
		let parentWin = window;
		while (parentWin !== window.top) {
			if (parentWin.document.referrer) {
				try {
					const url = new URL(parentWin.document.referrer);
					urls.push(url.origin);
				} catch (e) {
					console.error(e);
					return [];
				}
			}
			// @ts-ignore
			parentWin = parentWin.parent;
		}
		return urls;
	}
  }

It expects to get the page's origin from document.referrer in the iframe.
According to MDN: Inside an <iframe>, the Document.referrer will initially be set to the href of the parent's Window.location in same-origin requests. In cross-origin requests, it's the origin of the parent's Window.location by default.
So if the iframe hadn't navigated, document.referrer would be the page's origin (and getAncestorOrigins() would work correctly). But the iframe has navigated and so it is set to the previous location (https://geamaps.dsl.vodafone.it/gea190_v4/web/gea_v4.html).
In other words: this is a bug in the site's Firefox-specific code.

Thanks for getting to the bottom of that! Notable quote from your snippet:

	var isFirefox = typeof InstallTrigger !== 'undefined';

They're detecting Firefox by checking for InstallTrigger rather than by UA-sniffing. So, assuming/hoping that their non-Firefox-specific codepath works for us (which is worth checking)... if we wanted to deploy an intervention, it'd probably be necessary-and-sufficient to unset InstallTrigger for this particular origin.

(In reply to Holger Benl from comment #6)

In other words: this is a bug in the site's Firefox-specific code.

Oh hmm, that's not a complete explanation I think.

In particular, in early-beta-and-Nightly, InstallTrigger is turned off (because we'd like to do that everywhere when we can, precisely to avoid this sort of issue) -- see https://searchfox.org/mozilla-central/rev/2966caf8129d1a0d6a382b5d851456169f1081f8/modules/libpref/init/StaticPrefList.yaml#5395-5401

So in Nightly, when we reach the code quoted in comment 6, we get isFirefox = false (I just confirmed in the JS debugger) -- and yet, we still get the broken outcome.

Ah, but we still take the "else" clause because location.ancestorOrigins is undefined in Firefox; whereas it's defined in other browsers:
https://developer.mozilla.org/en-US/docs/Web/API/Location/ancestorOrigins#browser_compatibility

So, tentatively, we would need to make two distinct changes to get to working behavior here:
(1) Turn off InstallTrigger for this site (it's already off in nightly/early-beta, but we need to un-define it in release builds, which I think we can do via an intervention)
(2) Implement location.ancestorOrigins (which seems to be tracked as bug 1085214).

We need both of those things in order to reach (and have any likeihood of successful trip through) the "if" body in Comment 6's quoted code.

BTW: when I step through that code in Chrome, BTW, I see that location.ancestorOrigins is the array [ "https://www.vodafone.it" ], and I confirmed I get the good outcome if I manually set location.ancestorOrigins to that value in Firefox when I reach this function.

(I wondered if we might be able to use an intervention hack to try to reach the return [location.origin] early-return, inside the very first else statement that's quoted in comment 6 -- but that doesn't work because location.origin is different and not-what-the-site-wants to get the good outcome here.)

Depends on: 1085214

So this is a combination of webcompat:needs-sitepatch and webcompat:platform-bug (for (1) and (2) respectively in comment 9).

Webcompat Priority: --- → P1

We need to update our intervention here to just a Chrome UA string.

Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2ab29c88c269 update intervention for vodafone.it; r=denschub,webcompat-reviewers
User Story: (updated)
Webcompat Score: --- → 9
Priority: P2 → P1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: