Skip to content
This repository

Several browsers show infinite loading status #215

Closed
xqiu opened this Issue February 29, 2012 · 78 comments
Xinyang Qiu

When I tried SignalR app with IE8, seems it always trying to show loading status in the status bar in IE8. The temp site is http://319c8b3d7b394b46b1b7b7eb67d32778.cloudapp.net/. Contact me privately for code. Thanks.

Similar issues:

Kowsheek Mahmood

This is the case with Safari (on Windows) as well.

steve flitcroft

The standard fix was to include a dummy iframe and set its src to an empty blank.htm file on the root of the site after say 100ms. This would force the loading bar to finish even if other iframes were busy. To avoid needing each site that uses signalr to include a blank.htm you could try creating a dummy iframe and setting its src property to about:blank in a setTimeout. This may force the progress bar to fill up. Let me test.

Damian Edwards
Owner

I tried the suggested fix previously in Firefox and it fixed the loading indicator issue there (although we don't use Forever Frame in Firefox), so hopefully it will work here for IE8 and Safari too.

steve flitcroft

This does work, just added the following to our app and it cures ie7/8

  window.setTimeout(function() {
        var $fakeFrame = $('<iframe style="height:0;width:0;display:none" src="/favicon.ico"></iframe>');
        App.$body.append($fakeFrame);
        $fakeFrame.remove();
    }, 1500);
EliteMikeS

I tried the code that redsquare posted, It works initially, but after a few minutes I'm getting the indicator again. I know an older version of signalR was not causing this issue. Any other suggestions would be greatly appreciated. I have a few months to figure this out.

steve flitcroft

I didnt leave it open that long on ie! It will be as the reconnect happens after 110 seconds. Maybe need to hook into the client reconnect event and do a similar thing to above? Will test it now to see if I can replicate.

EliteMikeS

so I actually added the logic to the signalr.js file. I put the code in the connect and reconnect part of the forever frame code and that seems to solve this issue, but while using fiddler, I came across a more alarming issue that may be the real cause to my problem.

Let me first say that I have this working in 3 basic demo apps. The problem resides in the web app where I'm trying to implement it.

For some reason, after the client receives data the first time from the hub, signalr is trying to reach http://myhost/signalr It appears it's trying to re-establish the long poll but fails.

I even tried to put my logic on a blank aspx page with the a basic echo function and its failing. Something is different about my existing project vs the demo ones I created.

David Fowler davidfowl closed this May 07, 2012
David Fowler davidfowl reopened this May 07, 2012
Benny Michielsen
BennyM commented May 14, 2012

Issue not only exists on Safari in Windows but also on Lion.

David Fowler
Owner

Mobile safari seems to have this behavior by default with SSE http://googlecodesamples.com/html5/sse/sse.html. I also see the same for longPolling on mobile safari. So I'm thinking that's by design. I can't repro the other behavior on IE8 or Safari on windows. Here's my test site:
http://signalr-demo.apphb.com/

I used http://www.browserstack.com/user/dashboard to do testing on different platforms.

Benny Michielsen
BennyM commented July 09, 2012

I've been able to reproduce it, if sporadically.

Add an image element to the sample stockticker.
Open a market in a browser.
Navigate with Safari to the stockticker
Hit refresh several times and eventually you'll get the spinning wheel and loading indicator, even when the page is fully loaded.

It should be noted I'm testing on IIS7 and thus using long polling.

Benny Michielsen
BennyM commented July 09, 2012

You can also reproduce it by going to http://jabbr.net/ , sign in & hit refresh. You'll get a loading indicator in Safari.

Benny Michielsen
BennyM commented July 11, 2012

I've been able to address the issue in Safari as explained on StackOverflow . I now start the connection (hub) in a timeout instead of doing it directly in the ready/load handler.

N. Taylor Mullen NTaylorMullen referenced this issue from a commit August 01, 2012
Commit has since been removed from the repository and is no longer available.
N. Taylor Mullen NTaylorMullen referenced this issue from a commit August 01, 2012
N. Taylor Mullen Fixed #215, #383 and #491
All the bugs fixed in this commit are duplicates.

Executing Javascript once the DOM yielded constant loading in some
browsers where they viewed the page as continuously loading since the
entire page had not been loaded, even though the DOM had.  Fixed this
issue by re-routing the connection.start call to the window.load event
by default but also allowing the user to overwrite the default via the
startAfterPageLoad flag.
d2b5c60
N. Taylor Mullen NTaylorMullen closed this issue from a commit August 01, 2012
N. Taylor Mullen Fixed #215, #383 and #491
All the bugs fixed in this commit are duplicates.

Executing Javascript once the DOM yielded constant loading in some
browsers where they viewed the page as continuously loading since the
entire page had not been loaded, even though the DOM had.  Fixed this
issue by re-routing the connection.start call to the window.load event
by default but also allowing the user to overwrite the default via the
startAfterPageLoad flag.
d2b5c60
N. Taylor Mullen NTaylorMullen closed this in d2b5c60 August 03, 2012
N. Taylor Mullen
Collaborator

Applied Feature label to this since we added waitForPageLoad option for the javascript client with pull request #578.

Yngve Bakken Nilsen

I'm still getting this issue with SignalR v0.5.3.3.3.

Current workaround is to create a fake iframe and remove it, some milliseconds after page load.
Problem is that everytime I get a response from the server (via SignalR), it displays the message in statusbar again.

N. Taylor Mullen
Collaborator

Could you provide repro? Also, what version of Safari are you using?

Yngve Bakken Nilsen

Yeah. It's a basic SignalR setup in MVC4 with a hub. No fancy stuff. And it's on IE8 running on a Windows XP virtual machine. IIS7.5 in Windows 7.

Repro:

  • Install SignalR from Nuget
  • Add one hub
  • Define a method on client side in javascript.
  • call the method from hub (server side)

Waiting of course for the $.connection to be established with a callback in .done()

See how the tab keeps loading, and statusbar displays "waiting for ...." with foreverFrame as transport.

khushal999p

Not working ... safari 5.1.7 keeps on loading How to fix this issue....anyone?

N. Taylor Mullen
Collaborator

Safari for windows? I'm not able to repro via 5.1 on Mac

N. Taylor Mullen
Collaborator

Reopening due to known IE8 continuance and limited versions of Safari reproduction.

N. Taylor Mullen NTaylorMullen reopened this September 12, 2012
khushal999p

Yes, Safari 5.1.7 on windows

khushal999p

and also in safari 5.0.5

David Fowler
Owner

Keeping a running list of browsers where this happens:

  • iPhone 4 safari (event source)
willdean

This has become a serious problem for us with iOS6 Safari on iPad - we find that once the browser is in its 'load indicator spinning because of SignalR' state, it no longer loads new images, which completely breaks our application. We can live with the cosmetic nasty of the loading indicator, but the fact that the browser is semi-broken in this state is much more serious. It wasn't a problem before iOS 6.

khushal999p
David Fowler
Owner

@khushal999p and @willdean Try adding a setTimeout before calling with connection.start as the callback as a workaround.

willdean

@davidfowl - we don't find that works in this case (I know it's the standard way of avoiding this type of problem, but iOS 6 Safari seems resistant). What we see is that everything's OK while the timeout's still running, but once it expires and SignalR starts up then we get a permanent 'loading' spinner, and failing image loading.

willdean

@davidfowl - yes, absolutely - there's probably nothing to do but wait for Apple to fix it. Gutting to be at the mercy of a dominant vendor with a vested interest in shipping a bad browser... Brings back terrible memories ;-)

Chrome on iOS six works OK, if people are looking for a workaround.

Stephen Halter
Collaborator

Another potential workaround for iOS 6 Safari is waiting on $(window).load instead of the DOM ready event to start your connection. The former shouldn't fire until all resources have completely loaded.

willdean

@halter73 Thanks - but our experience is we can wait 10000 ms after the page loads (during which time the page shows as fully loaded and function correctly), but then if we start SignalR, the loading spinner appears and image updates break.

Damian Edwards

Can we find out exactly which browsers are exhibiting this problem with the latest source. Sync up with Taylor to find out scenario specifics.

ramaila

no body gave a correct answer.can anybody give me correct answer to this

ramaila

@rustd how can i contact you for the code.there is no way for me to contact you for the code.please provide the code

David Fowler
Owner

@ramaila There's no correct answer to this thats why the bug is still open. It has not been resolved for all browsers and we don't have a definitive list of browsers where this happens.

ramaila

This is so sad.I hope this gets resolved soon.

Mark Calder

Just in case anyone else has this issue, the explanation link is out of date, here's an update: http://www.realsoftwareblog.com/2013/01/ios6-mobile-safari-web-applications.html
Any word on resolution by Apple?

jberke

We just found with our implementation the the page loads fine on iOS6, but it shows as still loading; however any attempt to open a new page or connection to the server fails until we stop signal-r. We turn off signal-r and it works fine. Will get details on all the versions shortly...

jberke

Setting a timeout didn't work for us. The issue appears on IOS6 and IOS5 using Signal-r .5.3 from Nuget. The pages do appear to be loading.

willdean

I've build a very simple test/demo of this problem and am hosting it at http://sigr.inpin.co.uk if anyone wants a look.
The demo shows that the page stops being able to load images while there's a Server Sent Events request pending. This happens both with SignalR and with a very simple direct use of EventSource.

This demo fails in iOS6.01 Safari but works in Chrome on the same device.

Given that I can demo this with purely with EventSource, it hardly feels like a problem for SignalR at all.

Whatever it is, it's absolutely nothing to do with not finishing the initial page load, which is why the canonical setTimeout solutions don't work.

ramaila

@willdean can you provide source code for your demo application and also was that using signal R?

willdean

@ramaila - There's nothing of any interest in the server-side source - an empty hub, basically. All the source of any interest is in the page, which you can view with the browser.

jberke
Raghav Khunger

Is this issue fixed? I am still seeing this issue (status bar shows loading status continiously) in IE8 with Signalr 1.0rc2 version. Even on https://jabbr.net/ it keeps on saying "Waiting for.. " status with cursor in loading state. I have attached the screenshot for it.
2-8-2013 1-24-24 PM

David Fowler
Owner

@rustd can you take a look at this again and come up with a definitive list of browsers where this still happens?

jberke
khushal999p
David Fowler
Owner

@khushal999p no ETA. It'd be great if people could help the investigation instead of just asking for an ETA.

khushal999p
David Fowler
Owner

@khushal999p we'll fix it as soon as we figure out how to fix it.

VIvek Thakur

@davidfowl Is it possible that the signalR team talk to Microsoft IE team and get a quick fix? Pardon me for my assumption, as I think SignalR is close to Microsoft so the SignalR team has a better chance to fix this issue than ordinary mortals like us :)

David Fowler
Owner

It's not just IE that's broken has this issue and we don't plan to support every version of IE. So the current goal is to come up with a list of browsers that have this issue and then decide which ones are worth fixing. That has not been done to date.

VIvek Thakur

AFAIK, IE8 has the maximum browser share for all IE browsers (around 24%). So fixing this issue for IE8 should be a top priority else using SignalR in enterprise products is useless. We have enterprise clients who just cannot upgrade to IE9 (thanks to Microsoft) so they are stuck with IE8. I want SignalR to be usable in such enterprise environments. Else like others, we too will have to ditch this technology until a fix is available. I am wondering why Microsoft is not taking it seriously considering it owns IE8 and Signalr teams.

David Fowler
Owner

Thanks for the feedback.

pranay dutta

same issue i had made an chat engine evrythng is working fine in win8 7, server 2008 2012 2000
but i obsereved that my application is getting stucked into loading phase in win xp (any sp) and any browser combination

Javier Azaret

Regarding the problem being able to load images with iOS. If you host the images on another domain then it will grab the images with no problem. Just thought it might be a workaround for some. Alternatively try hosting the SignalR server to a different domain. Some ideas that may help. Still waiting for a better solution.

This page goes into some further details: https://discussions.apple.com/thread/4466216?start=0&tstart=0

JMacPSU

I spent the day exploring the internet for solutions to this problem. This is quite a frustrating problem. Without changing too much code, I have it working pretty decently in IE8. It's not perfect but it might be acceptable until something better comes along.

Here's what I changed.

Added function to jquery.signalR-1.0.1.js on line 1487 (in the forever frame section)
(This function is from redsquare's post)

function stopBrowserLoading() {
    var $fakeFrame = $('<iframe style="height:0;width:0;display:none" src=""></iframe>');
    $('body').append($fakeFrame);
    $fakeFrame.remove();
}

Then I added a call to this in the start function of the forver frame (line 1350, right after the variable declaration):

setTimeout(stopBrowserLoading, 1500);

Then I added a call to this in the receive function of the forever frame (line 1425, right after the variable declaration):

    stopBrowserLoading();

That is it. I was thinking I may need to place this in the reconnect function (as suggested above by EliteMikeS). I couldn't get this event to fire though, maybe someone can let me know if it is needed there.

Again, this isn't a perfect solution but it's the best I could up with after spending all day on it. This has only been tested in IE8 at this point. Hopefully will help someone.

Raghav Khunger

Hi,

I did as mentioned above i.e added fake iframe code but I am still seeing the "Waiting for.." status in IE8 status bar.

JMacPSU

@raghav-khunger Does it go away after the initial 1.5 second delay and then come back, or is it constantly there? I still see it every once in a while as well but it goes away because the receive function in which we added this code gets called on an interval.

David Fowler
Owner

@raghav-khunger @JMacPSU Did you guys try forcing longpolling as a transport? Does it only happen with forever frame?

JMacPSU

@davidfowl I just tried it with forcing longpolling as a transport. I put a breakpoint in to make sure my stopBrowserLoading function was not called. And it wasn't. The result was the browser did NOT show the loading indicators. So it seems to only occur when the forever frame is used.

Is it better to just use longpolling? What are the pros and cons? The fix I listed above works pretty well for me, although not perfectly. It still will flash up the 'Waiting for...' in the status bar, but it goes away very quickly. So if it's not a performance or security concern, maybe the longpolling would solve this problem?

Raghav Khunger

@JMacPSU Can you paste the changes you did? May be gist or jsfiddle for that? I just want to confirm I have applied the exact change you mentioned?

JMacPSU

Here is the Forever Frame part of the source code with my changes integrated. I have not made any changes anywhere else in the code so I am only posting this section for brevity.

/* jquery.signalR.transports.foreverFrame.js */
// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.md in the project root for license information.

/*global window:false */
/// <reference path="jquery.signalR.transports.common.js" />

(function ($, window) {
    "use strict";

    var signalR = $.signalR,
        events = $.signalR.events,
        changeState = $.signalR.changeState,
        transportLogic = signalR.transports._logic;

    signalR.transports.foreverFrame = {
        name: "foreverFrame",

        supportsKeepAlive: true,

        timeOut: 3000,

        start: function (connection, onSuccess, onFailed) {
            var that = this,
                frameId = (transportLogic.foreverFrame.count += 1),
                url,
                frame = $("<iframe data-signalr-connection-id='" + connection.id + "' style='position:absolute;top:0;left:0;width:0;height:0;visibility:hidden;' src=''></iframe>");

            setTimeout(stopBrowserLoading, 1500);

            if (window.EventSource) {
                // If the browser supports SSE, don't use Forever Frame
                if (onFailed) {
                    connection.log("This browser supports SSE, skipping Forever Frame.");
                    onFailed();
                }
                return;
            }


            // Build the url
            url = transportLogic.getUrl(connection, this.name);
            url += "&frameId=" + frameId;

            // Set body prior to setting URL to avoid caching issues.
            $("body").append(frame);

            frame.prop("src", url);
            transportLogic.foreverFrame.connections[frameId] = connection;

            connection.log("Binding to iframe's readystatechange event.");
            frame.bind("readystatechange", function () {
                if ($.inArray(this.readyState, ["loaded", "complete"]) >= 0) {
                    connection.log("Forever frame iframe readyState changed to " + this.readyState + ", reconnecting");

                    that.reconnect(connection);
                }
            });

            connection.frame = frame[0];
            connection.frameId = frameId;

            if (onSuccess) {
                connection.onSuccess = onSuccess;
            }

            // After connecting, if after the specified timeout there's no response stop the connection
            // and raise on failed
            window.setTimeout(function () {
                if (connection.onSuccess) {
                    connection.log("Failed to connect using forever frame source, it timed out after " + that.timeOut + "ms.");
                    that.stop(connection);

                    if (onFailed) {
                        onFailed();
                    }
                }
            }, that.timeOut);
        },

        reconnect: function (connection) {
            var that = this;

            window.setTimeout(function () {
                if (connection.frame && transportLogic.ensureReconnectingState(connection)) {
                    var frame = connection.frame,
                        src = transportLogic.getUrl(connection, that.name, true) + "&frameId=" + connection.frameId;
                    connection.log("Updating iframe src to '" + src + "'.");
                    frame.src = src;
                }
                setTimeout(stopBrowserLoading, 100);
            }, connection.reconnectDelay);
        },

        lostConnection: function (connection) {
            this.reconnect(connection);
        },

        send: function (connection, data) {
            transportLogic.ajaxSend(connection, data);
        },

        receive: function (connection, data) {
            var cw;

            stopBrowserLoading();

            transportLogic.processMessages(connection, data);
            // Delete the script & div elements
            connection.frameMessageCount = (connection.frameMessageCount || 0) + 1;
            if (connection.frameMessageCount > 50) {
                connection.frameMessageCount = 0;
                cw = connection.frame.contentWindow || connection.frame.contentDocument;
                if (cw && cw.document) {
                    $("body", cw.document).empty();
                }
            }
        },

        stop: function (connection) {
            var cw = null;
            if (connection.frame) {
                if (connection.frame.stop) {
                    connection.frame.stop();
                } else {
                    try {
                        cw = connection.frame.contentWindow || connection.frame.contentDocument;
                        if (cw.document && cw.document.execCommand) {
                            cw.document.execCommand("Stop");
                        }
                    }
                    catch (e) {
                        connection.log("SignalR: Error occured when stopping foreverFrame transport. Message = " + e.message);
                    }
                }
                $(connection.frame).remove();
                delete transportLogic.foreverFrame.connections[connection.frameId];
                connection.frame = null;
                connection.frameId = null;
                delete connection.frame;
                delete connection.frameId;
                connection.log("Stopping forever frame");
            }
        },

        abort: function (connection, async) {
            transportLogic.ajaxAbort(connection, async);
        },

        getConnection: function (id) {
            return transportLogic.foreverFrame.connections[id];
        },

        started: function (connection) {
            if (connection.onSuccess) {
                connection.onSuccess();
                connection.onSuccess = null;
                delete connection.onSuccess;
            } else if (changeState(connection,
                                   signalR.connectionState.reconnecting,
                                   signalR.connectionState.connected) === true) {
                // If there's no onSuccess handler we assume this is a reconnect
                $(connection).triggerHandler(events.onReconnect);
            }
        }
    };

    function stopBrowserLoading() {
        var $fakeFrame = $('<iframe style="height:0;width:0;display:none" src=""></iframe>');
        $('body').append($fakeFrame);
        $fakeFrame.remove();
    }

}(window.jQuery, window));
David Fowler
Owner

That's great to know on IE the problem is only with forever frame. We can focus on that first then move onto the IOS clients.

Raghav Khunger

I tested the same in IE8 and can confirm that the code provided by @JMacPSU worked :+1:

Here is the brief explanation of his code:

  1. "stopBrowserLoading" function added to simulate fake frame inside the browser.
  2. "setTimeout(stopBrowserLoading, 1500)" in "start" method added so that a fake iframe can be inserted as soon as the connection is started which will remove the progress bar in status bar afterwards.
  3. "stopBrowserLoading();" in "receive" method added so that a fake iframe can be inserted every time we receive any response from server via signalr. This is to fix the issue where progress bar was appearing after sometime on receiving response from server. EDIT:
  4. "setTimeout(stopBrowserLoading, 100);"added in the "reconnect" function for the same behavior in reconnect case.

Please correct me if I miss something in the above explanation.

Also, so far after applying the above code I am not facing any issue with SignalR with Chrome and FF, working as it was before.

@davidfowl Can this be added in core when this is tested at your end?

JMacPSU

The only thing you missed was that I also inserted:

setTimeout(stopBrowserLoading, 100);

in the "reconnect" function. I found a scenario to force reconnect to be called in the debugger and noticed this call was also needed there with a small (100ms) delay.

Raghav Khunger

@JMacPSU Thanks. I added this as fourth point in my comment.

pranay dutta

the problem is not with ie8 my application is working fine in ie8 + win7 but with ie8 +winxp its not doing great the loading is infinite and also signalr is neither receiving nor sending ny data but it works fine with win xp and chrome

problem is with foreverframe only as it get stucked in forever frame in the above scenario

N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
Commit has since been removed from the repository and is no longer available.
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Added a LoadPreventer which manages adding and removing dummy iframes…
… from the dom

- This prevents the infinite loading icon in IE8 and below (does not
happen for > ie8)

#215
2b24d2f
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Modified the attachedTo member to be an integer that is incremented
- Essentially just reference counts the connections that are attached to
the loadPreventer
- Also changed the way I create garbage frames.  Moved the variable into
the inner closure

#215
eef7122
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Added a LoadPreventer which manages adding and removing dummy iframes…
… from the dom

- This prevents the infinite loading icon in IE8 and below (does not
happen for > ie8)

#215
b154185
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Modified the attachedTo member to be an integer that is incremented
- Essentially just reference counts the connections that are attached to
the loadPreventer
- Also changed the way I create garbage frames.  Moved the variable into
the inner closure

#215
784e28b
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Added a LoadPreventer which manages adding and removing dummy iframes…
… from the dom

- This prevents the infinite loading icon in IE8 and below (does not
happen for > ie8)

#215
ff0e484
N. Taylor Mullen NTaylorMullen referenced this issue from a commit March 22, 2013
N. Taylor Mullen Modified the attachedTo member to be an integer that is incremented
- Essentially just reference counts the connections that are attached to
the loadPreventer
- Also changed the way I create garbage frames.  Moved the variable into
the inner closure

#215
eec5a7f
Xiaohong Tang
Collaborator

On IE8, this fix blocks debugging on SignalR script when use foreverFrame, the breakpoint can't be set for JS debugger

N. Taylor Mullen
Collaborator

After discussion earlier today we wanted to increase the interval in which we add/remove iframes so that will further make debugging difficult

Xiaohong Tang
Collaborator

now on IE8 the breakpoint can be set and debugging work for the page with the fix on my machine. (Last night, the page with the fix debugging didn't work, but at the same time other page debugging worked, don't know what happened at that time)

Xiaohong Tang
Collaborator

verified for multiple connections on IE8 /IE7, about the fix causing IE8 Developer Tools / Script interval refresh, we just wait for customers feedback.

Xiaohong Tang Xiaohongt closed this March 27, 2013
N. Taylor Mullen NTaylorMullen reopened this March 28, 2013
N. Taylor Mullen
Collaborator

This was fixed for ie8 in the next release, there is still a loading issue in ios and android. Reopening.

Yngve Bakken Nilsen

I would propose closing this issue, and opening a separate one targeting more specific browsers. Now that IE8/7 is fixed that would be useful to know by looking at this thread.

what about a new issue specifying iOS and Android, with a reference to this issue?

David Fowler davidfowl closed this March 29, 2013
blaster151

Wow - before finding this thread I was wrestling with a sudden break in behavior in Safari on iOS, stuff that had worked before stopped, and I hadn't made the connection to the iOS6 upgrade until now. It makes sense! Dynamically loaded images would no longer appear, but it wasn't clear that this was related to SignalR. My fix was to plug in a behind-the-scenes image preloader for all anticipated images that I knew my page could dynamically load, and that resolved the issue for me.

Nilay

@davidfowl , @yngvebn

Can you give me the issue number specific iOS if created a new one while closing this issue , as we are getting error in safari browser, I need to track the issue.
FYI I have posted Issue #1586 , which was closed against this issue.
I have also updated latest signalR(Version 1.0.1), however it din't work to fix the issue I have reported.

jflee
jflee commented April 25, 2013

What is the latest for this issue? I'm using v1.0.1 too but facing the same issue on iOS Safari, can someone guide me to the solution? Thanks!

willdean

@jflee - there is no 'solution', because the problem is that iOS Safari has a broken server-sent events implementation. Some work-arounds are: Use Chrome instead of Safari, preload images so that you're not trying to load them while SignalR is active, and apparently there are some possibilities of loading images from other domains, which I haven't tried and might be difficult to implement anyway.

Javier Azaret

@jflee take a look at issue #1406 aerlijman has an acceptable workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.