Could you check your proxy settings? Chrome uses the system proxy settings, but Firefox does not.

All three browsers share same network configuration, I checked it.

Deleted: Screenshot_10.png 20.3 KB

	Screenshot_10.png 20.3 KB View Download

I tried to reproduce this problem on another machine, but as you can see even 20-second requests work fine.
So I do not understand why they fail on my main machine (

Deleted: Screenshot_11.png 62.6 KB

	Screenshot_11.png 62.6 KB View Download

Are you using any extensions? Is it reproducible with a fresh profile? Can you provide a net-log[1]?

1: https://www.chromium.org/for-testers/providing-network-details

Thanks!

>Are you using any extensions?
No

>Is it reproducible with a fresh profile?
Yes

More details in my previous comments and links.

>Can you provide a net-log?
Here I reproduced it 2 times in 2 sessions in clear Chromium (search for 'Request Timeout'):

Deleted: chrome-net-export-log.json 397 KB

chrome-net-export-log.json 397 KB View Download

Deleted: chrome-net-export-log2.json 379 KB

chrome-net-export-log2.json 379 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The log says the server is replying with 408 after the client sends the body data.

t=320264 [st= 5143]     -HTTP_STREAM_REQUEST
t=320264 [st= 5143]     +UPLOAD_DATA_STREAM_INIT  [dt=0]
t=320264 [st= 5143]        UPLOAD_DATA_STREAM_INIT  [dt=0]
                           --> is_chunked = false
                           --> net_error = 0 (?)
                           --> total_size = 255
t=320264 [st= 5143]     -UPLOAD_DATA_STREAM_INIT
                         --> is_chunked = false
                         --> net_error = 0 (?)
                         --> total_size = 255
t=320264 [st= 5143]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=320264 [st= 5143]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                           --> POST /push_and_poll HTTP/1.1
                               Host: workflowy.com
                               Connection: keep-alive
                               Content-Length: 255
                               Accept: application/json, text/javascript, */*; q=0.01
                               Origin: https://workflowy.com
                               X-Requested-With: XMLHttpRequest
                               User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3402.0 Safari/537.36
                               Content-Type: application/x-www-form-urlencoded
                               Accept-Encoding: gzip, deflate, br
                               Accept-Language: en-US,en;q=0.9
                               Cookie: [596 bytes were stripped]
t=320264 [st= 5143]        HTTP_TRANSACTION_SEND_REQUEST_BODY
                           --> did_merge = false
                           --> is_chunked = false
                           --> length = 255
t=320264 [st= 5143]       +UPLOAD_DATA_STREAM_READ  [dt=0]
                           --> current_position = 0
t=320264 [st= 5143]          UPLOAD_DATA_STREAM_READ  [dt=0]
                             --> current_position = 0
t=320264 [st= 5143]       -UPLOAD_DATA_STREAM_READ
t=320264 [st= 5143]        UPLOAD_DATA_STREAM_READ  [dt=0]
                           --> current_position = 255
t=320264 [st= 5143]     -HTTP_TRANSACTION_SEND_REQUEST
t=320264 [st= 5143]     +HTTP_TRANSACTION_READ_HEADERS  [dt=10159]
t=320264 [st= 5143]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=10159]
t=330423 [st=15302]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                           --> HTTP/1.1 408 Request Timeout
                               Date: Wed, 02 May 2018 05:11:53 GMT
                               Content-Type: text/html; charset=iso-8859-1
                               Content-Length: 301
                               Connection: keep-alive
                               Server: Apache/2.4.29 (Ubuntu)
t=330423 [st=15302]     -HTTP_TRANSACTION_READ_HEADERS

I don't think this is XHR specific.

+Internals>Network

Network triager here. I've tried to reproduce it locally using Chrome Canary 64.0.3423.2 on Mac and I could not reproduce. 

My notes:

- Initial opening of https://workflowy.com/s/oiR.7h6EvycZiE took several minutes both with Chrome and Firefox.

- After finally opening the page navigation didn't result in any errors and responsiveness was visually comparable between Chrome and Firefox.

- I've noticed that in Chrome HTTP2 session was established and used, but net log files from comment 6 don't have HTTP2 session and use HTTP/1.1 instead. 

- The server has been upgraded from Apache/2.4.29 to Apache/2.4.33, could that have made a difference?

Could you try again and provide netlogs from machine which reproduces the problem and machine that works as expected?

I installed extension "HTTP/2 and SPDY indicator" and noticed that for example for www.facebook.com it indicates using of HTTP/2 ("h2" protocol on the network panel) and also I can see related sessions on chrome://net-internals/#http2, for www.google.com it indicates using of SPDY only, but for that test page it doesn't indicate using or any of those, and no HTTP/2 session appears. Network panel shows using HTTP/1.1 for all the requests.

Checked that in Firefox the test page works also over HTTP/1.1
It is all on Windows.

>The server has been upgraded from Apache/2.4.29 to Apache/2.4.33, could that have made a difference?
No, nothing changed for me. So new netlogs do not make sense.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This looks very much like a server bug (Or middlebox bug).  We send the request, send the upload body, and then the server sends an error indicating it didn't receive the body (Or we took too long to send it).

Finally resolved. 

The problem was caused by my antivirus software (SSL traffic scanner feature). 
When I concluded that AV is not the reason, I tried to temporarily disable it (there is a special option for this), but yesterday I found that this disabling doesn't actually disable that SSL scanner. So I turned it Off manually in advanced settings and problem just gone.

This was also the reason that network protocol was downgraded from HTTP/2 to HTTP/1.1 for that page.

I still don't understand why only in Chrome such environment caused problems, but not in Firefox and Edge.

The issue can be closed.

FireFox doesn't use system settings.  Edge doesn't yet support TLS 1.3 (Or could be some other small difference in our TLS implementations).