Closed
Bug 1332617
Opened 8 years ago
Closed 8 years ago
ups.com does not show time and costs on localized versions
Categories
(Web Compatibility :: Site Reports, defect, P2)
Web Compatibility
Site Reports
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: roger.periat, Unassigned)
References
()
Details
(Whiteboard: [sitewait])
Attachments
(3 files)
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...
Reporter | ||
Updated•8 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.
Comment 2•8 years ago
|
||
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•8 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)
Comment 4•8 years ago
|
||
Is it possible for you to do a screen capture video of this so that we can see exactly what is going on?
Reporter | ||
Comment 5•8 years ago
|
||
Screenshots here: https://www.dropbox.com/s/1an2s21g35y7l1w/ups_ff.pdf?dl=0
(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. ;)
Comment 7•8 years ago
|
||
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.
Updated•8 years ago
|
Component: Untriaged → DOM
Comment 8•8 years ago
|
||
Triage meeting: we cannot reproduce it on Mac Nightly 54. We saw the contents on the right side as expected.
Comment 9•8 years ago
|
||
(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•8 years ago
|
||
I can't reproduce it with Nightly on Win 7, I guess UPS ficed it.
Comment 11•8 years ago
|
||
(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
Closed: 8 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 12•8 years ago
|
||
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...
Comment 13•8 years ago
|
||
(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 → ---
Updated•8 years ago
|
Summary: ups.com does not show time and costs → ups.com does not show time and costs on localized versions
Comment 14•8 years ago
|
||
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•8 years ago
|
||
French locale is affected too. That's why I see the bug with Release and not with Nightly which is en-US.
Comment 16•8 years ago
|
||
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)
Updated•8 years ago
|
Priority: -- → P2
Comment 18•8 years ago
|
||
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
Comment 19•8 years ago
|
||
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)
Comment 20•8 years ago
|
||
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...
Comment 21•8 years ago
|
||
Thanks Dennis! I reached out to a contact at UPS, setting this to sitewait.
Whiteboard: [needscontact] → [sitewait]
Comment 22•8 years ago
|
||
Our contact is going to pass this report along internally. Will update when we hear back.
Comment 23•8 years ago
|
||
Our contact replied:
"Reproduced, will go in next prod release."
Comment 24•8 years ago
|
||
Another update: "Fix went in late yesterday"
Let's close this report as fixed.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 25•8 years ago
|
||
Great work! Thank you very much to all of you for investigating in this problem! Really really great!
Roger
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•