Visual Studio 2019/2022 debugging site remains at about:blank

[iprak]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

When debugging a sing page web application using Visual Studio with Chrome or Edge as browse target, VS launches the browser as something like this

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=55961 --no-first-run --no-default-browser-check --user-data-dir=C:\Users\_____\AppData\Local\Microsoft\VisualStudio\17.0_ca437560\WebTools\45106691_34FBCA4 about:blank.

The debug url actually is define as http://localhost:1979/HSWeb/ in the project and is somehow passed to the browser during debugging.

But the browser window continues to remain at about:blank

This was noticed just around Dec 26 which coincides with 1.40.2 where a related localhost issue was reported.

Upgrading to 1.40.8 did not help.

A specific URL where the issue occurs

about:blank

Steps to Reproduce

Start debugging (F5) the web application against using Chrome or Edge.

Expected behavior

The browser should continue navigating to the debug url as before.

Actual behavior

Browser remains at about:blank

uBlock Origin version

1.40.8

Browser name and version

Chrome 97.0.4692.71, Edge 97.0.1072.62

Operating System and version

Win10 20H2 OS build 19042.1415

[uBlock-user]

Disable Suspend network activity until all filter lists are loaded setting and try again.

[iprak]

I am unable to find this setting on Filters lists tab or Settings tab

Is it suspendTabsUntilReady in advanced setting?

[gorhill]

Did you try without uBO?

[iprak]

@gorhill Yes.

[iprak]

Setting suspendTabsUntilReady=false in Advanced settings restored the previous behavior.

[gorhill]

I fail to see how uBO is causing the issue.

Yes

So? Is the issue present without uBO?

[gorhill]

Somebody else able to investigate code will have to look into this one, I do not have Visual Studio and your local configuration.

[iprak]

The issue only surfaces when uBO is installed.

[iprak]

The issue does not seem to happen in the dev build 1.40.9.1

I think this might have something to with tab reloading which now has been removed.

VS launches Chrome/Edge in a separate user-data folder with about:blank e.g. "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=58562 --no-first-run --no-default-browser-check --disable-extensions --user-data-dir=C:\Users\iprakash\AppData\Local\Microsoft\VisualStudio\16.0_51656dfe\WebTools\10B84E65_1F1847B8 about:blank.

After that VS debugger communicated with Chrome over websockets and then eventually asks it to navigate to the actual debug url. This initial handshake navigation errors out/aborts.

[12:24:28.889 UTC] To client: {"seq":0,"type":"response","request_seq":5,"command":"configurationDone","success":true}
[12:24:28.889 UTC] To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"ClientRequest/configurationDone","data":{"Versions.DebugAdapterCore":"6.8.9","Versions.DebugAdapter":"4.13.0","Versions.Target.CRDPVersion":"1.3","Versions.Target.Revision":"@adefa7837d02a07a604c1e6eff0b3a09422ab88d","Versions.Target.UserAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36","Versions.Target.V8":"9.7.106.18","Versions.Target.Project":"Chrome","Versions.Target.Version":"97.0.4692.71","successful":"true","timeTakenInMilliseconds":"0.9906","requestType":"request"}}}
[12:24:29.586 UTC] ← From target: {"id":18,"result":{"frameId":"4E2F4DED425A8E8DAEE0463A7EAEBDB6","loaderId":"19240E00E58E3F49D0BB118B6167B77D","errorText":"net::ERR_ABORTED"}}
[12:24:29.588 UTC] ← From target: {"method":"Page.frameStartedLoading","params":{"frameId":"4E2F4DED425A8E8DAEE0463A7EAEBDB6"}}
[12:24:29.592 UTC] ← From target: {"method":"Runtime.executionContextsCleared","params":{}}
[12:24:29.593 UTC] To client: {"seq":0,"type":"event","event":"loadedSource","body":{"reason":"removed","source":{"name":"VM5","path":"<eval>/VM5","sourceReference":1000}}}
[12:24:29.593 UTC] ← From target: 

[gorhill]

uBO can't block navigating to a URL, but can block the network request for the main document. This means that even if the network request is blocked, the tab should have started navigating to the target URL, and it should show in the address bar -- at which point if uBO force a reload of the tab, it would force a reload of that URL. Can you reproduce the issue in 1.40.8 if you disable all the filter lists such that there are zero filters to enforce? (and there should be no rules either -- I want to know whether the issue is uBO blocking some communication between the browser and VS).

[iprak]

Unselecting all filters still gives the same problem.

Funny thing is that setting either true or false for suspendTabsUntilReady fixes the issue.

[gwarser]

Funny thing is that setting either true or false for suspendTabsUntilReady fixes the issue.

Valid values are yes, no and unset strings. Setting it to something else will probably skip reloading here: https://github.com/gorhill/uBlock/blob/554241be46891c12a0d23ba1799856aba1822b64/src/js/traffic.js#L1154

[gorhill]

Unselecting all filters still gives the same problem

Just to be sure, you have no block rules either in "My rules"?

[iprak]

There were no rules. This was in a new machine which did not have uBlock installed.

[gorhill]

So after all it does appear that forcing a reload of the currently active tab at launch is causing the issue -- this unconditional reload of the currently active tab at launch has been removed in the current dev build, in favor of reloading only if network requests were seen for a given tab before all lists were loaded.

Additionally, there is a new setting which can be toggled by the user if ever the maybe-reload-tab-at-launch is causing unforeseen issues in some edge cases.

[kolyanet]

To solve the issue of launching debugging through the browser in Visual Studio/Rider/Visual Studio Core on Windows 11, I checked the value of a parameter in the registry at:

HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
The RemoteDebuggingAllowed parameter must be set to 1

Here are the steps to open the registry editor and check/update this parameter:

1. Open the Run dialog by pressing Win + R.
2. Type regedit in the box and hit Enter to open the Registry Editor.
3. Navigate to the path:
   HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome.
4. Look for the parameter named RemoteDebuggingAllowed.
   • If it doesn't exist, create it:
     • Right-click in the right panel, select New -> DWORD (32-bit) Value.
     • Name it RemoteDebuggingAllowed and set its value to 1.
   • If it already exists, ensure its value is set to 1.