ups.com does not show time and costs on localized versions

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: roger.periat, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sitewait], URL)

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

open: https://wwwapps.ups.com/calTimeCost?loc=en_US&WT.svl=PNRO_L1


Actual results:

right side is empty


Expected results:

on the right the ups prices should appear. It does in chrome, ie and edge but not in firefox.
firefox debugger showed a json.parse error, not sure if this is the reason...

Comment 1

2 years ago
I'm able to reproduce the issue, even in very old versions of Firefox like FF33.
There is a script error in jQuery lib 1.11.1 embedded in the webpage.
Same as Loic. I can not reproduce this issue all the way back to FF3. Can you try with a new clean profile? This may fix the issue. Go to about:support click Refresh Firefox in the left corner.
Flags: needinfo?(roger.periat)
(Reporter)

Comment 3

2 years ago
I did a "Firefox bereinigen" on about:support (top right corner in FF 50.1.0 on Win 10 64bit).
Same behavior: https://wwwapps.ups.com/calTimeCost?loc=en_US&WT.svl=PNRO_L1 does *not* show the costs on the right side. I double checked it with FF 50.1.0 on Ubuntu 16.04 (64 Bit). The costs are shown on Ubuntu 16.04, no issue with this setup.
Flags: needinfo?(roger.periat)
Is it possible for you to do a screen capture video of this so that we can see exactly what is going on?

Comment 6

2 years ago
Created attachment 8830644 [details]
Screenshot-IE11vsFF50.jpg

(In reply to Justin [:JW_SoftvisionQA] from comment #2)
> Same as Loic. I can not reproduce this issue all the way back to FF3. Can
> you try with a new clean profile? This may fix the issue. Go to
> about:support click Refresh Firefox in the left corner.

Maybe you read wrongly my comment, but I'm able to reproduce the reporter's issue in the current version and the old ones. ;)
Interesting. I see what is expected each time. I even got on Mozregression to see how far back I could reproduce this. Lets try and find a component for this so that a dev can look at it.
Component: Untriaged → DOM
Triage meeting: we cannot reproduce it on Mac Nightly 54. We saw the contents on the right side as expected.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #8)
> Triage meeting: we cannot reproduce it on Mac Nightly 54. We saw the
> contents on the right side as expected.

I will try with Win later.

Comment 10

2 years ago
I can't reproduce it with Nightly on Win 7, I guess UPS ficed it.
(In reply to Loic from comment #10)
> I can't reproduce it with Nightly on Win 7, I guess UPS ficed it.

Thanks for re-testing it.

Everything works correctly with FF51 on Win10.

Thanks for reporting this issue, :roger.periat. I am going to close this due to the latest testing results by several folks. Please feel free to reopen it if you still encounter this.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 12

2 years ago
Created attachment 8837034 [details]
screenshots showing fail with FF51.0.1 on Win10 Pro 64Bit German

Perhaps a language thing? I do not have any Windows installation in which the UPS page works correctly with FF51. (Win7, Win 10). I had an old WInXP virtual machine with FF12.0 -> there it works(!). See screenshots for details.
Thank you for giving me a hint where to find the issue...
(In reply to roger.periat from comment #12)
> Created attachment 8837034 [details]
> screenshots showing fail with FF51.0.1 on Win10 Pro 64Bit German
> 
> Perhaps a language thing? I do not have any Windows installation in which
> the UPS page works correctly with FF51. (Win7, Win 10). I had an old WInXP
> virtual machine with FF12.0 -> there it works(!). See screenshots for
> details.
> Thank you for giving me a hint where to find the issue...

Oh, that's a good hint... I can reproduce this issue on several localized versions. I tried German and Japanese ones.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Summary: ups.com does not show time and costs → ups.com does not show time and costs on localized versions
I saw the syntaxerror on both German and Japanese versions. That might be the reason why...?

Hi Mike,
Would you please help check if there's something wrong in the website? Thanks.
===
SyntaxError: JSON.parse: unexpected end of data at line 2 column 1 of the JSON data[Weitere Informationen] 
jquery-1.11.1.min.js:4:15732
	m.parseJSON                            https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:4:15732
	checkIfCountryPairUAPEligible/jqxhr<   https://wwwapps.ups.com/assets/ctc/ctc_v07-06-20.cache.js:1:196938
	m.Callbacks/j                          https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:27239
	m.Callbacks/k.fireWith                 https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:28057
	x                                      https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:4:21841
	.send/b                                https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:4:25897
	.send                                  https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:4:25547
	.ajax                                  https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:4:21300
	isAddressClassificationAllowed         https://wwwapps.ups.com/assets/ctc/ctc_v07-06-20.cache.js:1:214940
	onInputPageLoadFunction                https://wwwapps.ups.com/assets/ctc/ctc_v07-06-20.cache.js:1:79022
	<anonym>                               https://wwwapps.ups.com/calTimeCost:1606:14
	m.Callbacks/j                          https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:27239
	m.Callbacks/k.fireWith                 https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:28057
	.ready                                 https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:29889
	J                                      https://wwwapps.ups.com/assets/framework/jquery/jquery-1.11.1.min.js:2:30255
Flags: needinfo?(miket)

Comment 15

2 years ago
French locale is affected too. That's why I see the bug with Release and not with Nightly which is en-US.
Created attachment 8837294 [details]
firefox (fr) 51.0.1 screenshot working

Interesting. I just tested pt-BR and fr locales, and this WFM. I wonder if being located in the US makes a difference?

Dennis, can you reproduce?
Flags: needinfo?(miket) → needinfo?(dschubert)
Yes, I can!
Flags: needinfo?(dschubert)
Whiteboard: [needsdiagnosis]
Priority: -- → P2
Okay, this is nothing we can fix. The function causing the JSON parse exception is the callback of this one:

> function isAddressClassificationAllowed() {
>   var destinationCountryCode = getDestination();
>   var params = "requestType=addressClassificationAllowed&destinationCountryCode=" +
>     destinationCountryCode;
>   var allowed = false;
>   $.ajax({
>     type: "POST",
>     url: "/ctc/CTCAjaxServlet",
>     dataType: "html",
>     data: params,
>     async: false,
>     success: function(data) {
>       var parsedJSONData = $.parseJSON(data);
>       if (parsedJSONData.addressClassificationAllowed != undefined) {
>         allowed = parsedJSONData.addressClassificationAllowed;
>       }
>     }
>   });
>   return allowed;
> }

However, there is nothing special in it. We simply get an empty response back. However, the same thing happens in Chrome and in fact, if you trigger the request via cURL, there is an empty response:

> curl 'https://wwwapps.ups.com/ctc/CTCAjaxServlet' \
>  --compressed \
>  -H 'Accept-Language: en,en-US;q=0.8,en;q=0.5,de-DE;q=0.3' \
>  -H 'Accept: text/html, */*; q=0.01' \
>  -H 'Cache-Control: max-age=0' --data 'requestType=addressClassificationAllowed&destinationCountryCode=US' \
>  -H 'Connection: keep-alive' \
>  -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \
>  -H 'DNT: 1' \
>  -H 'Host: wwwapps.ups.com' \
>  -H 'Referer: https://wwwapps.ups.com/calTimeCost?loc=en_US&WT.svl=PNRO_L1' \
>  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0' \
>  -H 'X-Requested-With: XMLHttpRequest'

It took me a bit to figure out what exactly is wrong, but the Accept-Language header is to blame here. If we change it to `Accept-Language: en-US,en;q=0.5`, the endpoint returns a JSON. If the primary accept language is anything except en-US, the request resturns a blank response, which obviously is invalid JSON.

Mike, this is technically not a webcompat issue, but since UPS is a fairly popular company, it might be still worth trying to reach out to them. What do you think? Moving into TE for now, since this is not a DOM issue.
Component: DOM → Desktop
Flags: needinfo?(miket)
Product: Core → Tech Evangelism
Whiteboard: [needsdiagnosis] → [needscontact]
Version: 50 Branch → unspecified
Great work, Dennis!

(and yeah, this should be in Tech Evangelism. It's not precisely web compat, because it happens in all browsers, but TE exists to cover all issues that need some form of outreach or education to resolve.)

I'm curious about Comment #0 saying this works as expected in Chrome & Edge, but *not* Firefox.
Flags: needinfo?(miket)
It did work in my Windows VM in Edge and Chrome - but it also worked in Firefox there. The VM is set to English only while my OSX has an English UI but a German locale (so timezones, currencies and number formats are 'correct'), which results in en-US *and* DE being added to the Accept-Language header. It actually didn't work in Chrome when I set the Windows VM to German only.

Probably, we build the language header differently than Chrome/Edge/Safari if there are multiple languages involved (notice how we put en before en-US if there is another locale). That could be something worth investigating further, but I am not sure if we should spend the time on that and if so, when. Clearly, UPS is doing something shady on the server side as I have never seen issues like this before.

This is, however, incredibly hard to test since we'd have to change system locales every time, requires a system reboot on every change, so that could turn out to be a quite lengthy process...
Thanks Dennis! I reached out to a contact at UPS, setting this to sitewait.
Whiteboard: [needscontact] → [sitewait]
Our contact is going to pass this report along internally. Will update when we hear back.
Our contact replied:
"Reproduced, will go in next prod release."
Another update: "Fix went in late yesterday"

Let's close this report as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
(Reporter)

Comment 25

2 years ago
Great work! Thank you very much to all of you for investigating in this problem! Really really great!
Roger
You need to log in before you can comment on or make changes to this bug.