1651625 - Websocket fails to connect to a Blazor server with Windows auth if Dev Tools is open

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect, P2)

Description

[Jani]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

• Install .NET Core:

dotnet --version
3.1.301

• Create a new Blazor application:

dotnet new blazorserver --auth Windows

• Run the "IIS Express" launch profile from Visual Studio 2019
• Open the page in Firefox, it works fine (try eg. navigation)
• Open Developer Tools
• Refresh the page

Actual results:

Firefox fails to connect the websocket and thus for example navigation won't work

Expected results:

Firefox should connect the websocket and thus for example navigation should work

Comment 1

[Jani]

Additional details:

• Closing dev tools fixes the issue and everything works again
• The last parameter seems to be the difference between a failing and successful connection:

Success:
2020-07-09 08:50:53.180000 UTC - [Parent 9500: Main Thread]: D/nsWebSocket WebSocketChannel::OnStopRequest() 000001F91297E000 [000001F913959040 000001F913959040 0]
Fail:
2020-07-09 08:51:04.865000 UTC - [Parent 9500: Main Thread]: D/nsWebSocket WebSocketChannel::OnStopRequest() 000001F90C768000 [000001F90E65B040 000001F90E65B040 80570021]

• Probably related to the new websocket debugger?

Comment 2

[Jani]

Also, this seems to be a problem with specifically localhost. TLS won't matter. I cannot reproduce this with a proper remote like https://blazor-demo.github.io/Counter.

Comment 3

[Jani]

Err, https://blazor-demo.github.io/Counter is using Blazor WebAssembly App, not Blazor Server App.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 5

[Dragana Damjanovic [:dragana]]

Nhi, can you find someone to take a look?

Comment 6

[Dragana Damjanovic [:dragana]]

Michal, was there something with devtools and websocket recently? Or was it about a patch that is backed out?

Comment 7

[Michal Novotny [:michal]]

(In reply to Dragana Damjanovic [:dragana] from comment #6)

Michal, was there something with devtools and websocket recently? Or was it about a patch that is backed out?

You probably mean bug 1621345, but it was backed out. Also if the bug would be involved, the behavior would be probably the same with devtools opened and closed. Unfortunately, I don't have Windows host, so I cannot follow STR from the description of the bug.

Honza, can you please find somebody from your team to have a look at this problem?

Jani, could you please attach full log? "timestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,nsWebSocket:5"

Comment 8

[Jani]

Attachment: issue-1651625-normal.txt-main.3484.moz_log

Here's a log without Developer Tools open

Comment 9

[Jani]

Attachment: issue-1651625-fail.txt-main.3484.moz_log

Here's a log with Developer Tools open exhibiting the bug.

Comment 10

[Jani]

Attachment: issue-1651625-fail2.txt-main.35068.moz_log

The attached issue-1651625-fail.txt-main.3484.moz_log seems a little different from what I previously captured. It also failed a little differently:

• Previously the page would load, but icons were broken and I couldn't navigate anywhere
• With this log, the page didn't event load, but a white page was displayed.

This issue-1651625-fail2.txt-main.35068.moz_log attachment fails first with displaying the page. The difference between these two logs is that in the first one I had to manually type my credentials and in the second one I configured integrated Windows Authentication for the Firefox profile.

Comment 11

[Jani]

Oh, and fail2.txt used http and fail.txt https. Both seem to fail, anyway.

I did some bisecting. To me the problem seems to be this commit:
https://phabricator.services.mozilla.com/D79137

Autoland 615cd7d5434a6a4e6c325a3a07ceb437a6dbf8bf was BAD whereas a744ed2bcb3d484b3b32ad77a9d9883c206bfca4 was GOOD.

Comment 12

[Jani]

Bringing up browser console, there is a lot of messages like this:

08:50:18.547 TypeError: this.weakMap.get(...) is undefined channel-map.js:57:38
    getChannelById resource://devtools/server/actors/network-monitor/utils/channel-map.js:57
    _findOpenResponse resource://devtools/server/actors/network-monitor/network-response-listener.js:413
    onStopRequest resource://devtools/server/actors/network-monitor/network-response-listener.js:377

Comment 13

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@bomsy: see the comment #12, this looks like related to the new "ChannelMap" introduced recently

Honza

Comment 14

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1651625 - Avoid error when weakmap does not contain any info for the channel r=honza

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ad6c0b1c8cfe
Avoid error when weakmap does not contain any info for the channel r=Honza

Comment 16

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/ad6c0b1c8cfe

Comment 17

[Hubert Boma Manilla (:bomsy)]

Jani,
Does this fix your issue? Would you be able to test on the latest nightly?

Thanks

Comment 18

[Jani]

Hmm, interesting enough, I couldn't reproduce this anymore on my daily driver 79.0b9. Digging for the fix, it seems this commit has fixed my issue:
https://phabricator.services.mozilla.com/D83010

In other words, I cannot fully verify the fix, but at least the problem has gone away.