www.expensify.com - layout is messed up

[learnedhoof]

URL: https://www.expensify.com/signin
Browser / Version: Firefox 51.0
Operating System: Windows 10
Problem type: Layout is messed up

Steps to Reproduce

1. Navigate to: https://www.expensify.com/signin
2. Use Style Editor to view style sheets.
3. Entry style.87facc4e.css.gz is not human-readable.

Expected Behavior: Page should be laid out properly.

Actual Behavior: Page appears to have no layout rendered. CSS appears to be loaded by but using Style Editor in Firefox seems that the .gz is not processed properly.

From webcompat.com with ❤️

[karlcow]

The site is responsive.
Confirmed in Firefox Nightly 51.0a1 (2016-08-14) (Left)
Working in Opera Blink. (Right)

Moving to needsdiagnosis

[karlcow]

Though working in Firefox 48. So I guess it's just a glitch of Firefox Nightly (which is expected: nightly are unstable versions).
Probably not a Web Compatibility issue.

[karlcow]

→ http HEAD https://d2k5nsl2zxldvw.cloudfront.net/dist/js-gz/module-class.5f0db86d.js.gz

HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 176035
Cache-Control: public
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 18495
Content-Type: application/javascript
Date: Sat, 13 Aug 2016 21:44:16 GMT
ETag: "b39281bacc7480af29c86bef4a812a5e"
Expires: Wed, 09 Aug 2017 21:16:17 +0000
Last-Modified: Tue, 09 Aug 2016 21:16:27 GMT
Server: AmazonS3
Via: 1.1 a6980301a21d33b02853b61627119c24.cloudfront.net (CloudFront)
X-Amz-Cf-Id: TALAoxh54o8wjIfVHHqjMEzS8XtL8xy5xyAfLf1g_lvrKX3EtgI4aw==
X-Cache: Hit from cloudfront
x-amz-meta-s3cmd-attrs: uid:105/gname:jenkins/uname:jenkins/gid:116/mode:33188/mtime:1470777377/atime:1470777376/ctime:1470777377

There might be an issue though. Let me reopen that:

Downloading 18.06 kB to "module-class.5f0db86d.js.gz"
 /   0.00 %     0.00 B     0.00 B/s  -:--:-- ETA
http: error: Incomplete download: size=18495; downloaded=66458
Done. 64.90 kB in 0.12901s (503.05 kB/s)

[denschub]

I'm unable to reproduce in 2016-08-15 and the file mentioned by @karlcow works for me. Maybe a recent deployment and not-fully-deployed CDN states?

[karlcow]

Still reproducing in Firefox Nightly 51.0a1 (2016-08-15) on macosx with a fresh profile.
But could be indeed a CDN issue.

[MDTsai]

unable to reproduce in Firefox 48~51 on ubuntu with clean profile.

[miketaylr]

Yeah, also WFM in Windows 10 on Nightly. @eleemoz can you confirm?

[karlcow]

Firefox Nightly 51.0a1 (2016-08-16), macosx, clean profile and I reproduce from Japan.
In the console:

Let's see:

GET /signin HTTP/1.1
Host: www.expensify.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Date: Wed, 17 Aug 2016 00:15:47 GMT
Content-Type: text/html
Content-Length: 2722
Connection: keep-alive
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM", policyref="/w3c/p3p.xml"
Cache-Control: no-cache
Set-Cookie: __cfduid=daa86952042e6bb6f8ae6f3a1d93901341471392947; expires=Thu, 17-Aug-17 00:15:47 GMT; path=/; domain=.expensify.com; HttpOnly
initialReferer=%28direct%29; expires=Sat, 15-Aug-2026 00:15:47 GMT; Max-Age=315360000; path=/; domain=.expensify.com; secure; httponly
browserGUID=57b3acb389df7; expires=Sat, 15-Aug-2026 00:15:47 GMT; Max-Age=315360000; path=/; domain=.expensify.com; secure; httponly
_stashedSupportLogin=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure
Content-Encoding: gzip
Server: cloudflare-nginx
CF-RAY: 2d38eefeef942e5d-NRT

Then let's take the next request after this:

GET /dist/css-gz/style.87facc4e.css.gz HTTP/1.1
Host: d2k5nsl2zxldvw.cloudfront.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.expensify.com/signin
Connection: keep-alive

Then the response:

HTTP/1.1 200 OK
Content-Type: text/css
Content-Length: 128426
Connection: keep-alive
Date: Thu, 11 Aug 2016 23:11:18 GMT
Last-Modified: Thu, 11 Aug 2016 22:47:54 GMT
Etag: "8525c46908966e333c20627f82158818"
x-amz-meta-s3cmd-attrs: uid:105/gname:jenkins/uname:jenkins/gid:116/mode:33188/mtime:1470955648/atime:1470955647/ctime:1470955648
Cache-Control: public
Content-Encoding: gzip
Expires: Fri, 11 Aug 2017 22:47:44 +0000
Accept-Ranges: bytes
Server: AmazonS3
Age: 435871
X-Cache: Hit from cloudfront
Via: 1.1 ebc77629c4b26fbccc1b57ff75631a1c.cloudfront.net (CloudFront)
X-Amz-Cf-Id: lSPWKmw5THguBsi6niD_CDHj_MYgmH-x17bw_jYQ4joNGHH6TrCGPA==

I wonder if others have different type of headers.

[denschub]

Huh! I just realized something weird. If the devtools are opened, the site breaks. If the devtools are closed, the site works. I think it could be related to being a gzipped asset and something being routed differently to allow debugging.

Reopening.

[karlcow]

@denschub nice try ;) I hoped you were right :p but for me it breaks also with devtools not opened. 😈

[learnedhoof]

Same, the breakage occurs regardless of whether devtools are open or not.
(Nightly 51, Windows 10)

[karlcow]

AH ! but I found something.
I restarted with add-ons disabled. @eleemoz could you try this:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

[karlcow]

FOUND!
Holy Cow 🐮 Sainte Vache 🐄

"No More 404" add-on from the pilot test center is tampering with the network traffic I guess.
https://testpilot.firefox.com/experiments/no-more-404s

[karlcow]

This is not a Webcompat issue but an issue to report on bugzilla and a serious one.
I will do that.

[denschub]

Hah! Now that one got my attention.

Aaaactually. This looks like an e10s bug. This does not reproduce with e10s disabled and there is bug 1292586 which smells like it can cause such weird issues. Can someone confirm that everything is fine without e10s?

(and, @karlcow, I wasn't joking. 😼)

[karlcow]

Issue filed in mozilla/testpilot#1256

[karlcow]

Also filed at internetarchive/wayback-machine-firefox#46

[learnedhoof]

Confirming that disabling NoMore404s seems to fix the problem.

[denschub]

1261585 was backed out, which fixed this issue. I don't think testpilot test authors could do something to prevent that in the future, but the issues are still open. However, I'm closing this one, since the issue is fixed.