1998663 - www.sellyourmac.com - Quote is not generated when finishing the sell form

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Mac OS X 10.15 and Windows 10
Firefox version: Firefox 144.0

Steps to reproduce:

1. Navigate to: https://www.sellyourmac.com/sell/macbook-pro.html
2. Proceed with the form introducing any data
3. Finish the last step and observe

Expected Behavior:
A quote is generated

Actual Behavior:
Nothing happens

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/187152

Comment 1

[Raul Bucata]

Attachment: Chr vs ff

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Alice0775 White]

It seems to work as expectd if setting the following prefs.
user_pref("intl.accept_languages", "en");
or
user_pref("intl.accept_languages", "en-us");
or
user_pref("intl.accept_languages", "ja,en-us,en");

However, this bug appears if setting the following prefs (default en-US build).
user_pref("intl.accept_languages", "en-us,en");

Comment 4

[Ksenia Berezina [:ksenia]]

Thank you, Alice. We can probably ship a sitepatch here to override Accept-Language header.

Comment 5

[Daniel Holbert [:dholbert]]

Yup, this is specifically the Accept-Language HTTP header.

When I perform the STR with network devtools open, there's a crucial request that shows up there to the URL https://www.sellyourmac.com/sell/get-price, which (in default-configured Firefox) returns a 403 response, with this data:

error	{ "status-code": "403", message: "Whoops! We have detected unusual activity. If you need help completing your quotes please email [e-mail] for assistance. Please include the error code: TevhNKeP", "request-id": "5ee819e79c843cd66a9473e995359055" }

If I copy-as-curl and execute the resulting command in the terminal (after removing -H 'Accept-Encoding: gzip, deflate, br, zstd' so that the result is human-readable), I see that same output in my terminal.

As Alice0775 White observed, this is the key header in that curl command:

  -H 'Accept-Language: en-US,en;q=0.5' \

If I adjust that curl command to e.g. remove en-US, then I get a successful HTTP response with a blob of JSON about my selected configuration. However, if I leave the locales untouched and simply adjust 0.5 to be any other number between 0 and 1, (e.g. 0.4, 0.6, 0.51, 0.9), then I also get a successful HTTP response.

So this site is getting confused specifically about the 0.5 there. Maybe their web server is treating 0.5 as meaning "no preference between these two" and it's tripping some error condition? (That's not what it's supposed to mean, but it's my best guess given that 0.5 seems to be magically able to trigger the badness here.)

Comment 6

[Daniel Holbert [:dholbert]]

Chrome and Safari both happen to send this header-value, with 0.9 instead of 0.5:

  -H 'Accept-Language: en-US,en;q=0.9' \

That gets the expected result here.

Comment 7

[Daniel Holbert [:dholbert]]

I filed bug 2000765 as a platform-bug, covering the fact that we're the only browser whose q-computation-algorithm happens to choose 0.5 here (which turns out to confuse this particular server).