JS client immediately start->stop->start connection, the first deferred.done is also triggered #2189

Closed
Xiaohongt opened this Issue Jun 21, 2013 · 5 comments

Comments

Projects
None yet
5 participants
Contributor

Xiaohongt commented Jun 21, 2013

Functional impact:
In JS client when immediately start->stop->start on connection, after connection become connected, the first deferred.done is also triggered.

Note, this is not regression.

Repro:
1). use the asp.net sample HubConnectionAPI
2). in HubConnectionAPI.js, update start function as below:

    start = function () {
        $.connection.hub.start({ transport: activeTransport, jsonp: isJsonp })
            .done(function () {
                $("<li/>").html("started transport: " + $.connection.hub.transport.name + " " + $.connection.hub.id)
                            .appendTo(messages);

                stopStartBtn.prop("disabled", false)
                            .find("span")
                                .text("Stop Connection")
                                .end()
                            .find("i")
                                .removeClass("icon-play")
                                .addClass("icon-stop");

            });

        $.connection.hub.stop();

        $.connection.hub.start({ transport: activeTransport, jsonp: isJsonp })
            .done(function () {
                $("<li/>").html("second started transport: " + $.connection.hub.transport.name + " " + $.connection.hub.id)
                            .appendTo(messages);

                stopStartBtn.prop("disabled", false)
                            .find("span")
                                .text("Stop Connection")
                                .end()
                            .find("i")
                                .removeClass("icon-play")
                                .addClass("icon-stop");

            });
    };

3). request HubConnectionAPI/Default.aspx on IE10 for webSockets transport

Expected result:
the first deferred.done is not triggered

Actual result:
the first deferred.done is also triggered, results like below:

•[11:19:05 PDT]: disconnected => connecting undefined
•[11:19:05 PDT]: connecting => disconnected undefined
•[11:19:05 PDT]: disconnected => connecting undefined
•[11:19:05 PDT]: connecting => connected 88c9e7e3-2fca-4199-992d-1c88dd4539ec
•[11:19:05 PDT]: 0d65e3e7-67d7-4365-91bd-a4ee6da24204 OnConnected
•[11:19:05 PDT]: 0d65e3e7-67d7-4365-91bd-a4ee6da24204 OnConnected
•started transport: webSockets 88c9e7e3-2fca-4199-992d-1c88dd4539ec
•second started transport: webSockets 88c9e7e3-2fca-4199-992d-1c88dd4539ec

Owner

davidfowl commented Jun 27, 2013

@Xiaohongt I'm not sure I understand this bug? Are you saying that calling start twice shouldn't return the original deferred object?

Contributor

Xiaohongt commented Jun 30, 2013

start->stop->start connection, the original deferred should be deleted and should not be triggered

@ghost ghost assigned NTaylorMullen Jul 30, 2013

Owner

DamianEdwards commented Jul 30, 2013

It seems the deferred returned from the first .start() call is succeeding when the second .start() call succeeds. The first one should've been rejected when .stop() was called.

NTaylorMullen added a commit that referenced this issue Aug 13, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Aug 13, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Aug 14, 2013

NTaylorMullen added a commit that referenced this issue Aug 15, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Aug 15, 2013

Contributor

gustavo-armenta commented Aug 15, 2013

I tried Xiaohong repro and I see the second start.done() is never invoked.
I expect a line on the webpage saying "second started transport: "

NTaylorMullen added a commit that referenced this issue Aug 16, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Aug 16, 2013

NTaylorMullen added a commit that referenced this issue Aug 16, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Aug 16, 2013

@ghost ghost assigned gustavo-armenta Aug 17, 2013

Contributor

gustavo-armenta commented Aug 19, 2013

tested Xiaohong repro, works as expected

•[10:41:19 PDT]: disconnected => connecting undefined
•[10:41:19 PDT]: connecting => connected e2983c02-92bb-4e14-88ca-031b05913a2f
•[10:41:19 PDT]: e2983c02-92bb-4e14-88ca-031b05913a2f OnConnected
•second started transport: webSockets e2983c02-92bb-4e14-88ca-031b05913a2f

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

NTaylorMullen added a commit that referenced this issue Oct 1, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Oct 2, 2013

NTaylorMullen added a commit that referenced this issue Oct 2, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Oct 2, 2013

NTaylorMullen added a commit that referenced this issue Oct 2, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Oct 2, 2013

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

Modified connection.stop to no longer deffer itself until the page ha…
…s loaded.

- It now unbinds the load event handler for the connection start.
- This allows for multiple starts/stops to occur during page load.
- This issue cannot be unit/functionally tested directly because it requires the page to be in the loading state.

#2189

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

Re-ordered when we clear private non-timeout based state.
- This way we can successfully reject connection deferrals.

#2189

NTaylorMullen added a commit that referenced this issue Oct 7, 2013

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