When downloading and running ST v0.9.10 on Win7Ult, it auto-opens in Chrome. But my UI looks nothing like the Getting Started screenshots. Clearly the CSS or something similar is missing. I tried a quick debug, but see nothing untoward. See the same thing in newest FF as well as IE11. Wish I could paste a screenshot!
Hmmm, how to describe… well everything is on the left. Only HTML text, boxes, etc all in one long webpage where I see every control. From Syncthing logo at the very top, to various links ending with a Close button. In fact, I see a lot of close buttons along the way.
NM, I see it is issue 598 in git, please attend as this makes syncthing unworkable. So +1 for me. As said, my environ is Win7Ult with IE11, FF31, Chrome36 - all giving the same result using both STv0.9.10 on 32 and 64 distros.
No, can’t see an AV getting in the way (running MSE here and it is quite docile) As already mentioned on git, most likely your embedded http daemon serves the (http://127.0.0.1:8080/bootstrap/css/bootstrap.min.css) css as text/plain which seemingly no browser then implements as CSS. That also goes for raleway.css btw. The actual content is returned in both cases, but the mimetypes are set to text/plain in the responses.
In firebug for ex. it shows zero references to any css rules for either of those CSS files, doesn’t matter which HTML element you select. It may fix it if you added type attrs to your HTML head’s link tags, if you can’t fix the actual http daemon mime output types for css files. Just a suggestion.
If a document contains style sheet links labeled as follows:
<link rel="stylesheet" href="A" type="text/plain">
<link rel="stylesheet" href="B" type="text/css">
<link rel="stylesheet" href="C">...then a compliant UA that supported only CSS style sheets would fetch the B and C files, and skip the A file (since text/plain is not the MIME type for CSS style sheets).
For files B and C, it would then check the actual types returned by the server. For those that are sent as text/css, it would apply the styles, but for those labeled as text/plain, or any other type, it would not.
If one of the two files was returned without a Content-Type metadata, or with a syntactically incorrect type like Content-Type: “null”, then the default type for stylesheet links would kick in. Since that default type is text/css, the style sheet would nonetheless be applied.
Things is though, when I run the binaries, it does return the correct text/css content type, as you can see in the screenshot. So I don’t doubt what you’re seeing, but I don’t understand how or why it happens. And it would seem to not affect everyone (apart from it not affecting me) or we’d have hundreds of Windows users screaming in here.
True. So this morning I tracked it a bit further. Brainwave to go check the registry - I mean, if Syncthing simply pumps the css and not explicitly set the mimetype either when serving the file or in html, it stands to reason that the default OS mimetype will be used. Lo and behold, for whatever reason, HKCR\.css was set to text/plain. So, a) there is how you can recreate the issue and b) to make syncthing more robust, I suggest you set the type of the HTML head links so your app will work independent of the default OS mimetype for something so critical - minimize points of failure so to speak.
End result, I changed the registry and now all three browsers are displaying the UI correctly.
