Blank Gui After Update To 1.4

[GreatMarko]

Windows XP (IE 8).

 

You've downloaded and installed the wrong version, Sync 1.4 isn't compatible with Windows XP - please see this article

[merlin]

 

You've downloaded and installed the wrong version, Sync 1.4 isn't compatible with Windows XP - please see this article

 

OK, Thanks.

 

You've downloaded and installed the wrong version, Sync 1.4 isn't compatible with Windows XP - please see this article

 

After testing this version (1.3.109), it does not support Proxy nor Approbations.

This is a problem!

 

No solution to use Proxy and Approbations on Windows XP ?

[olidie]

If I need to run IE on my computer that's more than one coffinnail for bt sync. IE is deinstalled from all pc's I work with since there's simply no use for it. If a programme wants to force me to install IE than it's goodbye....

[doubledeej]

@doubledeej / @ugumba - what internet security/anti virus software do you both run? Let's see if we can find a connection here!

 

(also, @doubledeej - what OS are you running?)

I'm just using Security Essentials and the built-in Windows Firewall.  I temporarily disabled both and the problem remains.

 

I've reset my IE zones and protected mode is disabled for all zones.  Still, same problem.

 

I have several apps of my own that use the OS' built-in web browser control and they all work fine.

 

I'm on Windows 7 Ultimate.  The problem also exists on my laptop and my PC at work, both on Windows 7 Pro.

[Harold Feit]

What internet explorer versions are on your machines?

[roco3]

The same here, sync 1.4.72 and ie 11. Anyone got this solved?

Disabling AVG antivirus (free) didn't work.

Edited August 31, 2014 by roco3

[doubledeej]

What internet explorer versions are on your machines?

Version 11.

[torvista]

If IE>8 is essential, why does the installer not check for this?

[merlin]

If IE>8 is essential, why does the installer not check for this?

 

+1

If Windows XP is not supported (because upgrading to IE>8 is not possible), why does the installer not check for this ?

[APC]

+1

 

Development lessons BT are learning the hard way today:

 

• You don't make big UI change like this, not test it properly and leave your software without a GUI - effectively making it unusable. At a minimum BT should have kept the old UI around for a version or two as alternative for a situation just like this.
• You never embed IE. Rather opt for embedding FireFox or Chrome. IE is customized by every big corporation, it is neither forward nor backward compatible even on CSS level.
• You don't assume Windows users are all "obviously" using IE. Reality is IE has not been even the 3rd most popular browser on Windows for almost 5 years.  Only place IE is more "popular" is in the Fortune 500 companies where a "Microsoft only"-policy exist, and they are definitely not even testing BTSync... yet.

 

Suggestion: Revert back to 1.3. And because BT also did not test reverting back and 1.3 won't run on the same settings as 1.4, do the following - Uninstall 1.4, then go delete your AppData\Roaming\BT Sync folder, reinstall 1.3 and setup all your folders again.  Worked for me.

[GreatMarko]

... not test it properly ...

Just to pick up on this particular point; Sync 1.4 was tested, including by members of this very community who signed up for the private Sync Alpha test program. Those members of the community participating in this alpha test have had access to Sync 1.4 builds since 22nd July, and have been actively testing and reporting their comments/concerns/feedback/bug reports to the developers since that time.

I can assure you that many of the concerns, feedback, and issues/bugs that people have taken to the forums to comment about in the past week since Sync 1.4 went public, were also previously identified & raised during the alpha phase as well, and reported to the developers.

As I am not one of the developers, I cannot speak as to why many of these haven't been addressed prior to the first "public" beta of Sync 1.4 which became available a week ago.

So, do keep on providing your valuable comments/feedback/bug reports here in the forums, but please don't blame the testers! They've done their bit (and are on your side, as many of them are also end-users like you!)... it's really in the hands of the developers/management to address the various concerns/issues raised to date in relation to 1.4...

[doubledeej]

+1

 

Development lessons BT are learning the hard way today:

 

• You don't make big UI change like this, not test it properly and leave your software without a GUI - effectively making it unusable. At a minimum BT should have kept the old UI around for a version or two as alternative for a situation just like this.
• You never embed IE. Rather opt for embedding FireFox or Chrome. IE is customized by every big corporation, it is neither forward nor backward compatible even on CSS level.
• You don't assume Windows users are all "obviously" using IE. Reality is IE has not been even the 3rd most popular browser on Windows for almost 5 years.  Only place IE is more "popular" is in the Fortune 500 companies where a "Microsoft only"-policy exist, and they are definitely not even testing BTSync... yet.

 

Suggestion: Revert back to 1.3. And because BT also did not test reverting back and 1.3 won't run on the same settings as 1.4, do the following - Uninstall 1.4, then go delete your AppData\Roaming\BT Sync folder, reinstall 1.3 and setup all your folders again.  Worked for me.

Not looking to pick a fight, or provoke anyone, but how does one "embed" Firefox or Chrome?  As far as I know neither of those browsers export embeddable objects.

 

According to the Mozilla site, the only way to embed Firefox is to actually include Firefox in your distributable.  Ick.  That means maintaining and updating their code as part of your own.  I don't think anyone would go for that.  It would make the product HUGE, and you'd really have to update the product every time a new Firefox build was released.  What a huge headache for the developers and end-users.

 

The Chromium embedded project doesn't exactly look like it is actively maintained.  And it is "still very much a work in progress."  Not exactly something I'd want to be part of a project I'm trying to support if I was a BTSync developer.  Only stable, production code for me.

 

The WebBrowser control in Windows, as goofy as it is to work with, is still the easiest solution.  Everybody running Windows already has it.  I suspect the problem here has more to do with the way the pages are being served rather than the way they're being rendered anyway.  In my case it is acting as if the CSS can't be downloaded.

[APC]

but please don't blame the testers! 

 

That may be Marko.  However, in my particular case I have a prime machine with Win7Ult, a lot of hardware, one AV running (MSE), IE11 up and running and up to date - in fact, my own machine is completely up to date with all the latest windows patches.  In fact, you could not ask for a better "up to date" example of a windows machine.  Yet, it fires up with a "textual" UI just like anyone else's.

 

So this "is it the IE version?", "is it the IE settings?", "is it the AV?" and "is it the firewall?", is typical dev-speak for grasping at straws.  Unless you embedded a virus in BTSync or the firewall is blocking localhost - both of which I highly doubt - the cause is obviously neither.  BT made two prime mistakes:

 

1. Choosing IE as browser on windows (since there are a millions things that can in fact be changed on it that will prevent your UI to load - most if not all of which you can pretty much disable on the embedded version btw)

    

2. It is clear that the HTML is in fact loading, but not the CSS - something which could and should have been tested for on any up to date Win7 with IE11 VM - before it was shipped to the testers.  Most likely a dev did actually test it, but forgot he actually had to tweak a registry setting or relpath along the way to get it to work.  Or tested it on 9 and 10, but not 11.

 

Fact is, was FF chosen none of this would have happened, since FF embed becomes a distinct copy in your app's folder which neither shares settings, nor folders with any other installed FFs, nevermind IE or Chrome.  Yes, it would bloat the BTSync install, but since when does a 10MB download bother windows users?  BT simply took the easy road with IE because it seemed obvious at the time it then wouldn't require any additional files to be part of the BTSync distro.  This would have been true... 10 years ago, before all the court cases and before Chrome, but is no longer the case.  I know because I too made the same mistake ... about 10 years ago.

 

Personally, these days, I would simply have steered clear of "embedded"-anything, and simply have added a HTTP GUI using the user's default browser to BTSync.  Which BT has been asked for in a million posts and which has been available on all the linux distros for months.  Yet, is still lacking on win.  Easiest thing in the world to embed a simple http daemon in BTSync, or use Lighttpd if you want a proper one.  Even more simple to make the BTSync popup menus point to URLs instead of actual win UIs - and then the user could use whichever browser they liked best and everyone would have been happy.  BT could have done this in half the time it took to do a halfhearted-attempt-to-embed-IE.

 

Look, don't get me wrong, the basic principles of BTSync is solid, it could be great product, I have hit my head against the same thing in the past and it obviously is a huge task to cater for all the platforms - so I have a) a huge amount of respect for the devs and a lot of sympathy, but shoot gents, a 10min session of due diligence and planning could have gone a long way to prevent a disastrous release like this one.  Just actually listening to the users of BTSync would have already had you 100% on the correct path.

[APC]

how does one "embed" Firefox or Chrome?  As far as I know neither of those browsers export embeddable objects.

 

All three main browsers have been embeddable for some years now  (FF was probably first since the late '90s if memory serves - I clearly remember using it as ActiveX control in Delphi 5 days - and did it that you could even choose if you wanted to use IE or FF as the engine) - takes some digging, some tweaking and a couple of SDKs to do it properly though.  As said, also wouldn't be my first choice these days.  If you really want a HTML-ish interface there are a million nice toolsuites available to do it with in anything from VS to Eclipse.

 

PS: Also less trouble than you would think to embed FF. Nice thing is you then have a safe and stable snapshot of FF only for your app.  As long as it works for your app, you don't have to worry about updates, fixes, patches, etc - it only every browse to localhost, so proxies, caching, security, etc all goes out the door.  All you really use is the rendering engine.  And, as long as it works for your HTML, it is irrelevant to ever update it.  These days however I would probably have gone for a WebKit rendering engine though - then you would have been compatible effectively with any Chrome or Android rendering - and master of just about 3 billion devices.... if, that is, I could not go for a pure httpd daemon and you held a gun to my head and forced me to embed "something".  Millions of projects like this: http://sourceforge.net/projects/wke/

[doubledeej]

All three main browsers have been embeddable for some years now  (FF was probably first since the late '90s if memory serves - I clearly remember using it as ActiveX control in Delphi 5 days - and did it that you could even choose if you wanted to use IE or FF as the engine) - takes some digging, some tweaking and a couple of SDKs to do it properly though.  As said, also wouldn't be my first choice these days.  If you really want a HTML-ish interface there are a million nice toolsuites available to do it with in anything from VS to Eclipse.

 

PS: Also less trouble than you would think to embed FF. Nice thing is you then have a safe and stable snapshot of FF only for your app.  As long as it works for your app, you don't have to worry about updates, fixes, patches, etc - it only every browse to localhost, so proxies, caching, security, etc all goes out the door.  All you really use is the rendering engine.  And, as long as it works for your HTML, it is irrelevant to ever update it.  These days however I would probably have gone for a WebKit rendering engine though - then you would have been compatible effectively with any Chrome or Android rendering - and master of just about 3 billion devices.... if, that is, I could not go for a pure httpd daemon and you held a gun to my head and forced me to embed "something".  Millions of projects like this: http://sourceforge.net/projects/wke/

Most of the projects to embed browsers have been defunct for quite some time.  I certainly wouldn't use one -- all of the ones I saw earlier today haven't been updated in months or years.  As for including someone's web browser code in my own distributable, yikes... that's something I don't think many developers would want to deal with or support.  What's so wrong with using the rendering engine built into the OS?

[APC]

What's so wrong with using the rendering engine built into the OS?

 

Nothing, if it works and you did it properly 

 

Which is exactly the point. IE doesn't and BT didn't.  I deal with IE issues every day in large companies (>100,000 emps) and this is mostly on intranets where one is in full control of standards, IE versions, etc. It is so bad, that certain IEs isn't even compatible with certain SharePoints - how ironic. I've even seen occurrences over the years where the latest stable IE release couldn't render microsoft.com. Everyone knows IE isn't on w3c spec and hasn't been for years now, and it has and always had lots of compatibility issues just between versions leading to statements like "BTSync will work with IE gt 8" but clearly it doesn't OOTB with IE11?  So, now what?  There is a "window" of IE OS browsers BTSync will work with?  Nice for cutting down market share... that is.

 

That being the bottomline of the argument, if you have to embed a browser, at least pick one that works from one version to the next or one that you have full control over which version your software will be using.  And even then consider not embedding at all and instead add a pure HTTP UI to BTSync which will simply render in whichever browser is default on the OS.  Works for Linux BTSync, as does the CLI - both of which are non-existent on win.

[ugumba]

The simple solution (yep - I noticed I'm echoing APC above):

 

BTSync for Windows should do the same as for Linux:

 

The engine runs headless without GUI, but exposes a small HTTP server on localhost, meaning that any browser can be used for configuration.

 

A tray icon is of course welcome, but instead of hosting the GUI on its own, it launches the HTTP server URL (http://localhost:port) in the user's default browser.  The tray icon process may of course use HTTP or DLL calls to show realtime information.

 

Problem solved, headaches gone.  Or am I missing something?

[matthewpapa]

+1

Seeing a blank page after I upgrade. I am using Windows 7 enterprise with IE 11 behind a corporate firewall. I have tried resetting security but no dice. Also tried a reinstall. Everything worked fine before. I used a vpn to direct connect to peers at home with 1.3 and was looking forward to using the proxy feature in 1.4. But i cannot configure it now.

 

Also + 1

for all of those complaining about 1.4 relying on IE. I recongnize this problem is likely due to IE. What a terrible piece of software to depend on. If we are going to use a web interface we might as well be able to use whatever browser we want. I only use IE to download firefox/chrome, and it is possibly the most disfuctional browser out there.

[exbigpiggy]

+1

As the person in my company spouting "forget dropbox, use btsync instead" This is really embarassing. On OSX and linux we have 1.4 working well but its unuseable on windows. The people saying go back to 109, great idea but you then need to re-setup all your shares again.

 

This is what I would expect from alpha software. My love of this sort of software can only go so far.

[APC]

Not that I would retract anything I suggested so far, but I have actually debugged and resolved this issue [without the source code] - BTSync can send a cheque when they actually make money from it

 

First, I simply assumed BTSync is not directly responsible and that it is the IE plugin's fault - which seems a safe assumption. The IE plugin works pretty straightforward, you simply give it files and it serves them.  Also, the symptoms seems pretty much that CSS was not being served to the embedded browser. I could especially reinforce this line of thinking when I also started looking at Syncthing and got almost an identical issue, but this time on three browsers FF, IE and Chrome.   So if neither BTSync and Syncthing explicitly set their CSS mimes in their HTML head tags, on windows, the registry would be used to determine the mimetype.  So I checked.

 

For whatever reason, it seems there are a lot of Windows machines for which the HKCR\\.css type is set to text/plain - which according to W3C spec would be considered invalid by the UA (browsers).  I corrected this and suddenly Syncthing was up and running on 3 different browsers.  Then upgraded BTSync to 1.4 again and boom - now works like a charm!

 

Suggestions:

• I'll keep to my mantra of adding a HTTP daemon and CLI to windows distro instead of embedding IE
• However, for now, BT should update 1.4 to explicitly set the type attr of the HTML linking the CSS so BTSync is independent of the OS mimetypes - minimizing points of failure
• And in the meantime, win users could simply correct their registry mimetype to get BTSync 1.4 to work.

 

Enjoy!

[Jan Derk]

I had de text only interface due to css not loading problem too on Windows 8. The registry trick by setting the css mime type to text/css fixed the issue for me. I would be nice if the installer checked and set this value during installation. 

 

Also as a 10 years developer of applications on many platforms: I agree that depending on embedded IE is not the wisest choice and will keep giving weird issues like the ones in this thread. 

[merlin]

Not that I would retract anything I suggested so far, but I have actually debugged and resolved this issue [without the source code] - BTSync can send a cheque when they actually make money from it

 

First, I simply assumed BTSync is not directly responsible and that it is the IE plugin's fault - which seems a safe assumption. The IE plugin works pretty straightforward, you simply give it files and it serves them.  Also, the symptoms seems pretty much that CSS was not being served to the embedded browser. I could especially reinforce this line of thinking when I also started looking at Syncthing and got almost an identical issue, but this time on three browsers FF, IE and Chrome.   So if neither BTSync and Syncthing explicitly set their CSS mimes in their HTML head tags, on windows, the registry would be used to determine the mimetype.  So I checked.

 

For whatever reason, it seems there are a lot of Windows machines for which the HKCR\\.css type is set to text/plain - which according to W3C spec would be considered invalid by the UA (browsers).  I corrected this and suddenly Syncthing was up and running on 3 different browsers.  Then upgraded BTSync to 1.4 again and boom - now works like a charm!

 

Suggestions:

• I'll keep to my mantra of adding a HTTP daemon and CLI to windows distro instead of embedding IE
• However, for now, BT should update 1.4 to explicitly set the type attr of the HTML linking the CSS so BTSync is independent of the OS mimetypes - minimizing points of failure
• And in the meantime, win users could simply correct their registry mimetype to get BTSync 1.4 to work.

 

Enjoy!

 

Good news !

 

But, how to make these changes in the registry on Windows XP?

(HKCR\\.css does not exist)

 

Thanks

[GreatMarko]

But, how to make these changes in the registry on Windows XP?

 

Instructions may be found in the Unofficial Troubleshooting FAQ

[merlin]

Instructions may be found in the Unofficial Troubleshooting FAQ

Thanks !

 

But bad new, the trick does not work on my computer (WXP)!

(The registry was already OK: https://lut.im/GTdvQH6t/RFAYOqAg).

The home page remains blank in BTSync.

 

(

[GreatMarko]

But bad new, the trick does not work on my computer (WXP)!

(The registry was already OK: https://lut.im/GTdvQH6t/RFAYOqAg).

The home page remains blank in BTSync.

Merlin, the registry "fix" ONLY works in cases where there's just plain text/no images/random layout in the UI. If you've got a completely blank UI - which you will have if you're using XP - this fix won't work.

In your case, as you're using Windows XP (and my apologies, I missed that nugget of information in your original post!), I'm afraid you're out of luck - Sync 1.4 isn't compatible with Windows XP, due to the fact that XP can't run anything higher than IE8 (and IE8 is what causes the entirely blank UI)

You would therefore need to use Sync 1.3.109 instead.