1794713 - Fedex site fails with valid tracking number (but works in Chrome)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Bruce]

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

[Anca Soncutean, Desktop QA]

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.

Comment 2

[Bruce]

Perhaps this information will be helpful.
http://forums.mozillazine.org/viewtopic.php?p=14941296#p14941296

Comment 3

[Bruce]

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

[Shane Hughes [:aminomancer]]

I'm able to reproduce the issue consistently. It never works. Works fine in Edge.
Reported: https://webcompat.com/issues/117975

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Tim Huang[:timhuang]]

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.

Comment 7

[Bruce]

This appears to be fixed. Thanks fo the Bugzilla team for their work.
Bruce

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[[e-mail]]

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

[zarokima]

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

[Jim Jeffery not reading bug-mail 1/2/11]

(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

[Dennis Schubert [:denschub]]

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.

Comment 13

[Kestrel]

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

[Matthew Turnbull [Bluefang]]

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

[Matthew Turnbull [Bluefang]]

Attachment: https://api.fedex.com/track/v2/shipments OPTIONS request

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

[Matthew Turnbull [Bluefang]]

Attachment: https://api.fedex.com/track/v2/shipments POST request

The POST request to https://api.fedex.com/track/v2/shipments

The request/response does not have the "access-control-allow-origin" header.

Comment 17

[Calin Tanase]

Verified this issue and could not reproduce it on Firefox versions 122 and 124.

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 124.0a1 (2024-01-28) / Firefox Release 122

Closing this as worksforme. Feel free to leave a comment and reopen if the issue is still reproducible on a new/clean profile.