Fedex site fails with valid tracking number (but works in Chrome)
Categories
(Web Compatibility :: Desktop, defect)
Tracking
(firefox-esr102 affected, firefox106 affected, firefox107 affected)
People
(Reporter: bawittmeier, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
Enter Fedex.com site
Enter a valid tracking number
Actual results:
Using this valid tracking number:
https://www.fedex.com/fedextrack/?trknbr=582566986755
This error: Unfortunately we are unable to retrieve your tracking results at this time. Please try again later.
Expected results:
Works correctly with Google Chrome and Seamonkey. Valid tracking information is provided.
Comment 1•2 years ago
|
||
I am able to reproduce this issue with the latest Firefox versions on Windows 10 and macOS 12, but only intermittently. Due to this fact I can’t determine a regression range, but this issue was at least present way back to the 87.0a1 version.
There is no error displayed inside the browser console, and after several refreshes attempts the proper content is displayed.
I will set a General component, feel free to move it to a more appropriate one, if the case.
Perhaps this information will be helpful.
http://forums.mozillazine.org/viewtopic.php?p=14941296#p14941296
I don't mean to be a pain but I'm not familiar with the Bugzilla notation. General component -- what does that mean? What happens now?
Comment 4•2 years ago
|
||
I'm able to reproduce the issue consistently. It never works. Works fine in Edge.
Reported: https://webcompat.com/issues/117975
Comment 5•2 years ago
|
||
Perhaps tracking protection folks can triage this more effectively than General? (I'm not sure whether or not it's actually a problem with tracking protection or some other mechanism.)
(This is also broken for me in nightly on Linux, and it works for me in Chrome.)
Comment 6•2 years ago
|
||
The tracking page works for me in Nightly at least. Would you be able to provide the info on the about:support
, especially the Important Modified Preferences
section, to help us debug this? Thanks.
This appears to be fixed. Thanks fo the Bugzilla team for their work.
Bruce
Comment 8•2 years ago
|
||
It's still broken for me in a clean profile on Nightly on Linux (build 20230217165316).
Note that on a clean profile, when I go to fedex.com , I first have to choose a region/language, and I chose United States - English. Then I'm redirected to the home page, where I can enter a tracking number.
Comment 9•2 years ago
|
||
Based in our investigation we could reproduce the issue with ETP on and off in Nightly channels.
We did note that it's not reproducible in release under a clean profile, but it is reproducible in nightly with a clean profile.
On first inspection this doesn't seem anti-tracking related
Comment 10•2 years ago
|
||
I am getting this issue in version 111.0.1, and can reliably "fix" and reproduce it. It is related to the "privacy.resistfingerprinting" config option. Fedex only works if it's turned off. If I turn it back on and relaunch Firefox, then it is again broken until I turn that option off.
Comment 11•2 years ago
|
||
(In reply to zarokima from comment #10)
I am getting this issue in version 111.0.1, and can reliably "fix" and reproduce it. It is related to the "privacy.resistfingerprinting" config option. Fedex only works if it's turned off. If I turn it back on and relaunch Firefox, then it is again broken until I turn that option off.
Confirmed on latest Nightly. 'privacy.resistfingerprinting' does indeed cause the error on FedEx
Comment 12•2 years ago
|
||
privacy.resistFingerprinting
breaks all kinds of things in many different ways. That's not surprising, and the reason why we do not suggest anyone to toggle that pref on.
However, this is unrelated to this report. Fedex' tracking sometimes fails in setups without p.rF enabled.
Updated•2 years ago
|
Comment 13•2 years ago
|
||
It works with privacy.resistFingerprinting
enabled if you grant permission to extract canvas data (look for the icon next to the padlock in the address bar).
Comment 14•2 years ago
|
||
I can still reproduce this problem with a new profile and the latest nightly build (20230416094854)
The console has this error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.fedex.com/track/v2/shipments. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 403.
Comment 15•2 years ago
|
||
The OPTIONS request to https://api.fedex.com/track/v2/shipments
The response does have "access-control-allow-origin: https://www.fedex.com"
Comment 16•2 years ago
|
||
The POST request to https://api.fedex.com/track/v2/shipments
The request/response does not have the "access-control-allow-origin" header.
Description
•