vodafone.it - The page fails to load
Categories
(Web Compatibility :: Site Reports, defect, P1)
Tracking
(Webcompat Score:9, Webcompat Priority:P1, 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:
- Navigate to: https://www.vodafone.it/eshop/contenuti/rete-vodafone/copertura-mobile-5g.html
- 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
Reporter | ||
Updated•2 months ago
|
Reporter | ||
Updated•2 months ago
|
Reporter | ||
Updated•2 months ago
|
Comment 1•2 months ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.
Updated•2 months ago
|
Updated•1 month ago
|
Comment 2•1 month ago
|
||
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.
Comment 3•1 month ago
|
||
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.
Comment 4•27 days ago
|
||
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:
- the page contains an iframe that loads https://geamaps.dsl.vodafone.it/gea190_v4/web/gea_v4.html
- that page contains a script that navigates to https://geamaps.dsl.vodafone.it/gea190_v4/web/gea.jsp?version=6.4&COP=5G
- that page loads the script https://geamaps.dsl.vodafone.it/gea190_v4/dwr/engine.js?version=6.4 (amongst others)
- that script initiates the request for https://geamaps.dsl.vodafone.it/gea190_v4/dwr/call/plaincall/WhitelistDomainsServiceFacade.areAllAncestorsDomainInWhitelist.dwr
- but at some point the iframe navigates to https://geamaps.dsl.vodafone.it/gea190_v4/web/gea_forbidden.html and the previous network requests from the iframe are cancelled
--> switching back to the webcompat team for diagnosis
Comment 5•27 days ago
|
||
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.
Comment 6•27 days ago
|
||
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.
Comment 7•27 days ago
|
||
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.
Comment 8•27 days ago
|
||
(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.
Comment 9•27 days ago
|
||
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.)
Comment 10•27 days ago
|
||
So this is a combination of webcompat:needs-sitepatch
and webcompat:platform-bug
(for (1) and (2) respectively in comment 9).
Updated•20 days ago
|
Assignee | ||
Comment 11•3 days ago
|
||
We need to update our intervention here to just a Chrome UA string.
Assignee | ||
Comment 12•3 days ago
|
||
Updated•3 days ago
|
Comment 13•1 day ago
|
||
Comment 14•15 hours ago
|
||
bugherder |
Assignee | ||
Updated•11 hours ago
|
Assignee | ||
Updated•3 hours ago
|
Description
•