Created attachment 8818875 [details] dldialog.png User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161215004017 Steps to reproduce: * Visited https://www.brain.fm/app/html/templates * Tried the same URL in Chrome which worked (if you see a blank page, it worked - the page is a bunch of script elements). * Tried the same URL with curl --compressed, which worked. Actual results: * Noticed that the page didn't display properly in Firefox dev ed 52.0a2 and instead showed a download dialog (see attachment) * Moz regression log: https://gist.github.com/anonymous/716892ad5736265e514aa548cbfc0e10 Expected results: * Page should have been decompressed properly and displayed as usual
I'd be happy to perform a mozreg on Nightly but currently all Nightly builds are broken for me due to bug 1320340 so it's difficult to test.
I can't reproduce it with FF53 on Win 7, issue specifici to Linux probably.
Component: Untriaged → Networking
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
I have tried it on linux and I can reproduce it on Nightly 53. But if I turn on logging to figure out what is happening it is not reproducible. :) Logging should not change behavior.
I have seen in dev-tools that there is a header Content-type: "application/x-gzip" if it shows dialog and this header does not exist if it does not show the dialog (from log I seen that we do not get such a header).
I cannot reproduce it all the time. I think it is a server issue.
(In reply to Dragana Damjanovic [:dragana] from comment #5) > I cannot reproduce it all the time. I think it is a server issue. Interesting. I can reliably reproduce this every time, even after turning on logging in about:networking. Are you able to see it work by refreshing repeatedly? I'm curious as to what you're doing differently to me.
Can't repro after updating today. I assumed there was a fix that had been pushed - running mozregression with --good=2016-12-16 --bad=2016-12-15 --find-fix --repo aurora gave me: 2:16.30 INFO: Narrowed inbound regression window from [40a2d269, 35f19f6b] (3 revisions) to [e92c50c1, 35f19f6b] (2 revisions) (~1 steps left) 2:16.30 INFO: Oh noes, no (more) inbound revisions :( 2:16.30 INFO: First good revision: 35f19f6baa6c2d853a438efff3d955a23823bbca 2:16.30 INFO: Last bad revision: e92c50c1c5cdd95b59f0a72f15e3aa2841908beb 2:16.30 INFO: Pushlog: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e92c50c1c5cdd95b59f0a72f15e3aa2841908beb&tochange=35f19f6baa6c2d853a438efff3d955a23823bbca I was suspicious, so I ran the same command again and got a totally different result: 1:40.78 INFO: Narrowed inbound regression window from [481d62db, 0da2d015] (4 revisions) to [f3353c8b, 0da2d015] (2 revisions) (~1 steps left) 1:40.78 INFO: Oh noes, no (more) inbound revisions :( 1:40.78 INFO: First good revision: 0da2d0158f98743c85d3ed279c3a4db691c2d4f5 1:40.78 INFO: Last bad revision: f3353c8bb6f3de41df3e889da27115d6e29a7e93 1:40.78 INFO: Pushlog: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f3353c8bb6f3de41df3e889da27115d6e29a7e93&tochange=0da2d0158f98743c85d3ed279c3a4db691c2d4f5 So I don't know what to make of that. I don't think it's telling us anything and I'm beginning to think this is indeed a server issue. I can confirm what was said about the "Content-Type" header above: > I have seen in dev-tools that there is a header Content-type: "application/x-gzip" if it shows dialog and this header does not exist if it does not show the dialog (from log I seen that we do not get such a header). I checked the network log and it would indeed appear as if it's definitely being sent (but only sometimes?): 2016-12-16 15:36:06.086150 UTC - [Socket Thread]: V/nsHttp index 61: date Fri, 16 Dec 2016 15:35:24 GMT 2016-12-16 15:36:06.086153 UTC - [Socket Thread]: V/nsHttp index 62: content-type application/x-gzip 2016-12-16 15:36:06.086156 UTC - [Socket Thread]: V/nsHttp index 63: x-frame-options SAMEORIGIN 2016-12-16 15:36:06.086159 UTC - [Socket Thread]: V/nsHttp index 64: x-backend-server brainfm-us-atl01.brain.fm 2016-12-16 15:36:06.086162 UTC - [Socket Thread]: V/nsHttp index 65: vary Accept-Encoding 2016-12-16 15:36:06.086165 UTC - [Socket Thread]: V/nsHttp index 66: strict-transport-security max-age=86400 2016-12-16 15:36:06.086167 UTC - [Socket Thread]: V/nsHttp index 67: server cloudflare-nginx 2016-12-16 15:36:06.086170 UTC - [Socket Thread]: V/nsHttp index 68: content-encoding gzip 2016-12-16 15:36:06.086173 UTC - [Socket Thread]: V/nsHttp index 69: cf-ray 3123347473f83476-LHR I'll take this up with their support again and see if there are any more ideas.
status-firefox50: --- → unaffected
status-firefox51: --- → unaffected
status-firefox52: --- → affected
status-firefox53: --- → affected
The pushlog for the fixed revisions shows nothing in networking (all graphics changes), and the pushlog for the broken revisions (https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f6f2e2b9fa87a1cf454dec44bcf52cd4f96288a0&tochange=0d52c1ee6bce8b6b8d0b1774ce4b15082e6b4854) only contains updates to the HSTS and HPKP preload lists. None of those changes would have caused or fixed a problem like this. Based on that, and other comments in the bug, marking this invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.