broken on safari (mobile+desktop)? getting a blank page #2921

Closed
lightsurge opened this Issue Jan 9, 2013 · 34 comments

9 participants

@lightsurge

I'm using iOS 6.0.1 on an iPad2 / desktop Safari 5.1.7

Works fine on android devices, and chrome[latest]/firefox[latest]/ie9 , but on Safari under the most basic of tests, going directly to login.persona.org/sign_in I get a blank page.

Below describes the issue well, but doesn't really solve it:
http://www.beetlebrow.co.uk/what-do-you-need/help-and-documentation/unix-tricks-and-information/safari-gzip-deflation-and-blank-pages

Below suggests this may be a bug related to ssl+safari+gzip+chunked in some web servers:
http://stackoverflow.com/a/14218811

All other websites working fine, and although I am testing behind a forward proxy, the persona website itself isn't being filtered given that it works fine in the other browsers behind the same proxy.

If nobody else has already reported this I guess it must be something wrong I'm doing, but I thought I'd post this just in case I'm not going mad and others are experiencing this.

@lightsurge

This is bizarre, I can also replicate on desktop with safari 5.1.7, works fine in chrome and internet explorer

@lightsurge

Not much by way of diagnostics to tell, but after 40 seconds transfer ends with a status 200 having transferred 0 bytes. This is the same for trying to download the js from the persona website or by attempting to access login.persona.org/signin
See attached screenshot
safari-persona

@lightsurge

This seems to describe the problem and a possible solution
http://www.beetlebrow.co.uk/what-do-you-need/help-and-documentation/unix-tricks-and-information/safari-gzip-deflation-and-blank-pages

Apart from just not gzipping js, this problem appears well known and the solutions seem to vary a lot depending on the server, so I guess this is one only the Mozilla folks can fix really.

@callahad
Mozilla member

Preliminarily assigning this as a 5-star. @jrgm -- do you have an iPad, and can you reproduce this issue?

@lightsurge

Like I say, you should be able to reproduce it just with a desktop machine and Safari (I was using 5.1.7).

If not, it must be some network peculiarity combined with (just) Safari, Persona and an environment like the one I'm in (large corporate). I definitely think it's something to do with gzip, perhaps in combination with SSL, possibly chunking? I've tried it through 3 different corporate-type forward proxies now, so its not peculiar to any one of those, Safari seems to draw a blank on any data the persona website attempts to send gzipped, so nor is it peculiar to any file. All other browsers receive fine.

@benadida

fwiw, it works ok on my safari 5.1.6 desktop

@benadida

and on ipad 6.0 (haven't updated yet)

@lightsurge

Unless something crazy happened in the last releases it must be peculiar to my environment then. For comparison here's an example of a gzipped SSL file transfer that did work in my environment on Safari.

https://developers.google.com/speed/articles/gzip

Main difference seems to be that here Content-Length is specified, and there's no 'Transfer-Encoding:chunked' as with persona
working-gzip

@lightsurge

Yup, tested from home and works fine. So its not a version of Safari/iOS problem, its an environment problem.

But... the work setup is the same old [proprietary] story, though, so I very much doubt it's unusual. Although, given this only affects Safari even if all those in that same old story used persona, the problem would nevertheless likely only ever rear up if someone brought their iPad into work (as they increasingly do), given safari on the desktop at work is minimal.

Hope you can fix it, as I doubt I can convince those on my end to trace some network transformation that's mucking up safari, when I can only quote it affecting persona.

@callahad
Mozilla member

Lowering to 4-stars since it's not a widespread issue. @fmarier since you were looking at making Persona faster, what are your thoughts on not gzipping for Safari users?

@fmarier
Mozilla member

@callahad gzipping text files like JavaScript ones usually makes a big difference (especially on slower connections), but there's no point in the page being fast if it's not going to be parsed/displayed properly by Safari :)

@shane-tomlinson
Mozilla member

I would be interested in knowing what in the environment is causing Safari to behave this way. Are we missing a header?

@lightsurge

Could also be the presence of the etag header, combined with safari and some web caching proxy behaviour

@gary-qi

It is a widespread issue! I don't know how many people are using Browser ID though

It has problem on safari 5.1.7 windows
It has problem on chrome iOS test on ipad and iphone

It's easily verifiable, how can you say it's not widespread?

Works for me on safari on iOS

@6a68
Mozilla member

@gary-qi, thanks for commenting. Few questions for you:

  • "works for me on safari on iOS" - does this mean you can or cannot verify the error on that platform?
  • safari 5.1.7 windows - what version of windows?
@gary-qi
@callahad
Mozilla member

Closing as WONTFIX:

No one has been able to reproduce the Mobile Safari issue, and even @lightsurge wasn't able to reproduce it on a different network.

@gary-qi reproduced the Windows Safari issue, but to be perfectly honest, Apple has discontinued Safari for Windows making it a legacy browser with extremely small market share.

I feel terrible typing that, but without steps to reproduce the issue on a current browser, I'm not sure it makes sense for the core staff to devote much more time to this.

We'd definitely consider a community-provided patch if the ops burden was low enough, but I would want to be certain that we weren't running into false positives and sending uncompressed content to clients that could support gzipped files.

@callahad callahad closed this Jan 29, 2013
@lloyd

note, chrome iOS is being tracked in issue #2034

@lightsurge

So a further report is noted and the response is to almost immediately close the issue? That makes no sense... The report from @qary-q might also have been environment not software related, but since you've closed this issue I presume you're not interested in pursuing it.

So I'm presuming you're not interested in getting any further reports along the lines of 'broken on safari (mobile+desktop)? getting a blank page'. So let's just not support Safari in environments that puzzle us, those environments should probably just sort themselves out. Why should Persona try and be something that suits everyone, when they of course should suit it.

@ozten
Mozilla member

We absolutely are interested in further reports, but we need complete steps to reproduce, before we can diagnose and fix an issue. If it's an environment issue and we can't reproduce the environment, there isn't much we can do.

The more you can troubleshoot, diagnose, or document the root cause, the more likely we can act on the issue.

This team has invested a lot of time in iOS and will continue to do so. Thanks again for your help and patience with intermittent issues.

@callahad
Mozilla member

Hi @lightsurge, I must apologize. I am genuinely conflicted on flagging this as "wontfix" and closing it. The closing is not meant dismissively, nor is it set in stone, though I certainly understand how it can be seen that way.

The additional activity brought this bug back to the top of my notifications, and offered a chance to reflect on its state:

  • Persona supports the latest stable release of all majors browsers. Safari for Windows has been discontinued, and is thus unsupported. That isn't to say the core team won't look into or try to fix bugs that crop up -- Issue #2858 involved a far more esoteric browser -- but we simply don't have the manpower to prioritize those issues.
  • You're the only person that's been able to reproduce this on iOS, and only on one network. Without a patch, steps to reproduce, or a complete diagnosis from you or another affected user, we're stuck. We don't have enough information to act.
  • We know that Persona works correctly on that same exact browser on other networks, so we don't currently have a way of turning off gzip without adversely affecting many other users.

We're absolutely interested in similar reports, but in the absence of those reports, and without evidence that the issue is impacting supported browsers in other environments, we simply don't have enough information to proceed.

Fundamentally, leaving the bug "open" felt dishonest: we'd welcome additional information, but we're not actively working on this particular issue.

@gary-qi

I don't want to complicate this thing, but I did a test http://myfavoritebeer.org/ at home without proxy. It works fine on safari 5.1.7 (7534.57.2) on windows XP. Earlier I reported failure similar to @lightsurge was behind a corporate firewall through proxy.

Thanks lloyd for iOS direction. Hope that one get fixed soon.

@shane-tomlinson
Mozilla member

@gary-qi, @lightsurge - When this problem manifests, can you take a screen shot of the request and response headers in Safari?

The steps to do so are quite convoluted, but it may provide an insight into what is going on.

1) In Safari on Windows XP, open 123done.org
2) Click the sign in button
3) In the dialog, open the Safari developer tools
4) click "Scripts"
5) Open the Javascript Console
6) Type "BrowserID.module.stopAll();" into the console and press enter
7) Close the Javascript Console
8) Click on Network
9) Type CTRL-R to reload the dialog
10) The first network request should be "sign_in"
11) On the right hand side, click "Headers"
12) Take a screen shot.

In particular, I am interested in seeing if the "Conent-Encoding" or "Content-Type" headers have been stripped and/or modified.

This is what it looks like in Windows XP/Safari 5.1.2 for me.

Safari 5 1 2 on Windows XP

@gary-qi

Thanks Shane for detailed steps.

I tried this in office behind proxy, but I couldn't get past the first one, sign in button refused to show, only a loading image, even after hours of wait.

Tried #6, since I didn't click sign in, couldn't find the function.
a

I also tested at home, it works fine, a bit slow though. Screen is just like yours.

home safari 123done signin

@lightsurge

Same here... as in #2921 (comment)

Just can't get as far as that

@shane-tomlinson
Mozilla member

@gary-qi, @lightsurge - oh, interesting. In both cases where you are behind the proxy, are 3rd party cookies enabled in Safari?

If you visit http://myfavoritebeer.org and click the "Sign in with Persona" button, does the dialog appear, but blank?

@lightsurge

Okay Fiddler2 with decrypted traffic showed more interesting headers.

Attempting to simply access https://login.persona.org/ showed that Safari successfully established CONNECT login.persona.org:443 but that was as far as it got. Fiddler then gets a 502, 'gateway refused requested connect' (it's not a proxy authentication problem, other sites fine).

Doing the same on Chrome, I get
CONNECT login.persona.org:443 RESPONSE: 200
CONNECT static.login.persona.org:443 RESPONSE: 200
then all files download fine.

So considering we have subdomain goings-on here I tested with: https://static.login.persona.org/v/520c400846/production/include.js which downloads fine in Chrome, not in Safari

same, in Safari it connects, then 502. These are the request headers:

CONNECT static.login.persona.org:443 HTTP/1.1
Host: static.login.persona.org
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Proxy-Connection: keep-alive
Connection: keep-alive

GET /v/520c400846/production/include.js HTTP/1.1
Host: static.login.persona.org
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Connection: keep-alive
Proxy-Connection: keep-alive

I suppose there isn't much point giving you the response headers.

For comparison, the request headers in chrome are:

CONNECT static.login.persona.org:443 HTTP/1.1
Host: static.login.persona.org
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.45 Safari/537.22

GET /v/520c400846/production/include.js HTTP/1.1
Host: static.login.persona.org
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.45 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

and response:

HTTP/1.1 200 OK
Vary: Accept-Encoding,Accept-Language
Cache-Control: public, max-age=31536000
Content-Type: application/javascript
Content-Encoding: gzip
Strict-Transport-Security: max-age=2592000; includeSubdomains
Date: Thu, 31 Jan 2013 10:56:08 GMT
Transfer-Encoding: chunked
Access-Control-Allow-Origin: https://login.persona.org
ETag: "15538-1358435473000"
Connection: keep-alive
X-Frame-Options: DENY

@lightsurge

@shane-tomlinson 3rd party cookies are enabled. Button does nothing because for the reasons above include.js is not downloaded

@lightsurge

Shouldn't this: Access-Control-Allow-Origin: https://login.persona.org
Be: Access-Control-Allow-Origin: https://static.login.persona.org

Probably doesn't matter, just a thought

@lightsurge

I've now tested without a proxy, but within the same network. Same problem, but response error is different.

fiddler 504 'server did not return a response for this request'

@lightsurge

Note I cannot access most of the resources on *.persona.org on safari either, same error

So this is nothing to do with gzip, and nothing to do with chunked transfer

For example, I can't access (edit: actually I can)
https://login.persona.org/v/7ad3be635d/pages/i/persona-logo-wordmark.png

But I CAN access
https://login.persona.org/v/61fe8c7a3b/pages/i/marketplace-header.png

That's so weird?! The response headers are different in Chrome compared to Safari, mainly just the addition of Content-Length and content-type:

Chrome:

Access-Control-Allow-Origin:https://login.persona.org
Cache-Control:public, max-age=31536000
Connection:keep-alive
Date:Thu, 31 Jan 2013 13:49:44 GMT
ETag:"24303-1358382478000"
Strict-Transport-Security:max-age=2592000; includeSubdomains
Vary:Accept-Encoding,Accept-Language
X-Frame-Options:DENY

Safari:

Access-Control-Allow-Origin:https://login.persona.org
Cache-Control:public, max-age=31536000
Connection:Keep-Alive
Content-Length:24303
Content-Type:image/png
Date:Thu, 31 Jan 2013 13:49:52 GMT
Etag:"24303-1358382478000"
Strict-Transport-Security:max-age=2592000; includeSubdomains
Vary:Accept-Encoding,Accept-Language
X-Frame-Options:DENY

@lightsurge

Sorry no, I can access the images, but I can't (definitely can't) access the scripts or stylesheets on Safari i.e.

https://static.login.persona.org/v/85ce3f9526/production/browserid.css

@lightsurge

I CAN access https://static.login.persona.org/v/85ce3f9526/production/en/browserid.js on Safari

So this is something that's peculiar to:
https://static.login.persona.org/v/85ce3f9526/production/browserid.css
and
https://static.login.persona.org/v/85ce3f9526/production/include.js

Sorry for all the noise, going to give in troubleshooting now before I go nuts

@lightsurge

btw although https://static.login.persona.org/v/85ce3f9526/production/en/browserid.js would download through safari, it was slow, and when decoding the response fiddler2 gave me a strange error:

'Chunked body did not terminate properly with 0-sized chunk'

Through safari, no such error and was fast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment