Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazor WASM Debugging in VS launches Edge with a separate user data directory #20915

Closed
analogrelay opened this issue Apr 16, 2020 · 11 comments
Closed
Assignees
Labels
affected-most This issue impacts most of the customers area-blazor Includes: Blazor, Razor Components Docs This issue tracks updating documentation Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-tooling Blazor specific tooling requests feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly reevaluate We need to reevaluate the issue and make a decision about it severity-nice-to-have This label is used by an internal tool

Comments

@analogrelay
Copy link
Contributor

@rynowak told me to just file something here to start with :). I'm sure this lives somewhere else, like in VS.

If I launch a Blazor WASM app in VS with Ctrl-F5, I get a new tab opened in my existing Edge browser window and everything is nice. My extensions are present, and I'm properly signed in to Edge, you can see my profile picture in the top-right:

The top-right of a Microsoft Edge browser window showing my profile picture

Cool cool cool cool.

Now, I launch with F5 to use the swanky new debugging features. Instead of a new tab, I get a new window. That's fine, I don't mind that. However, it's not signed in with my profile, so I don't get my extensions or existing cookies. This was annoying because I'm building an app that signs in to GitHub, and I didn't have my Github cookie or my password manager in order to log in again. Since I'm not signed in, my profile picture isn't in the top right:

The top-right of a Microsoft Edge browser window showing no profile picture

I noticed that VS launched msedge with a --user-data-dir=C:\Users\anurse\AppData\Local\Microsoft\VisualStudio\16.0_019f56a0\WebTools\EdgeUserData_E906737D_E10E9004-4C41-47FB-B7F0-6B3B57970109 parameter which seems to be why it's not picking up my normal profiles. This seems odd to me :(.

@analogrelay analogrelay added the area-blazor Includes: Blazor, Razor Components label Apr 16, 2020
@mkArtakMSFT mkArtakMSFT added the feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly label Apr 16, 2020
@mkArtakMSFT
Copy link
Member

Thanks @anurse.
I will follow up with the JS Debugger team regarding this.

@mkArtakMSFT mkArtakMSFT added the External This is an issue in a component not contained in this repository. It is open for tracking purposes. label Apr 16, 2020
@mkArtakMSFT mkArtakMSFT self-assigned this Apr 16, 2020
@SteveSandersonMS
Copy link
Member

As I understand it, it’s necessary to use a separate profile. Chromium browsers only support a single instance per profile directory, so if you already have a browser open then ask it to open a new one with different command line options (eg to open the debugging port) it will ignore the different options and continue using the existing instance.

The only way we can be sure to enable debugging is either:

  • Force the user to close all existing browser instances (extremely hostile)
  • Or, launch on a separate profile

@digeff
Copy link

digeff commented Apr 16, 2020

What @SteveSandersonMS said is correct. If you want to use your existing user data folder with your extensions and preference you'll have to close all existing browser instances before launching it from Visual Studio (you'll need to do this each time).

To configure Visual Studio to launch the browser with your existing user data folder you'll need to:

  1. Go to the Browse with... option:
    image
  2. Add... a new browser:
    image
  3. Configure the path to your browser, and use a custom ---user-data-dir argument pointing to your user data folder
    image
    In my PC they are:
    C:\Program Files (x86)\Microsoft\Edge Beta\Application\msedge.exe
    --user-data-dir="C:\Users<username>\AppData\local\Microsoft\Edge Beta\User Data"
  4. Ok to add it, and then optionally set it as the Default browser if you choose to.
  5. Browse with your user profile

@analogrelay
Copy link
Contributor Author

Ugh. That feels like a really unpleasant user experience. I get the issues, but from a user experience side it feels really unsatisfactory.

I’ve made it work (by logging in to the “alternate” profile) so I don’t really need to set up the new browser launch profile. I’m not sure most users would understand what’s going on here and why they don’t have any of their cookies and extensions.

@digeff
Copy link

digeff commented Apr 17, 2020

The 2 main restrictions that we have are:
1: If Chrome was launched without a debugging port (this is the normal launch), you cannot add one later, so we won't be able to debug it.
2. If you launch Chrome with a user profile that is already being used by another instance of Chrome, the existing instance is reused, so if Chrome is already running for that user profile, and it doesn't have a debugging port, you cannot add one unless you stop all instances of Chrome for that user profile first

The only alternative I can think of to avoid that experience would be for the user to chose a fixed port for Chrome, and modify all Chrome shortcuts to always open debugging with that fixed port, and then modify VS to also use that port too.

@anurse If you have any suggestions as to how we can improve the experience, we'd love to hear them :)

@analogrelay
Copy link
Contributor Author

Yeah, it certainly does seem like we’re stuck with what we’ve got :(. Maybe some way of notifying the user would help? And/or docs clarification?

And of course we could see about filing a chromium bug but I’m not super hopeful about that being resolved any time soon (if at all :)).

@mkArtakMSFT
Copy link
Member

Let's wait and see how community feels about this. Moving this to the backlog (as a potential docs improvement).

@mkArtakMSFT mkArtakMSFT added Docs This issue tracks updating documentation and removed External This is an issue in a component not contained in this repository. It is open for tracking purposes. labels Apr 20, 2020
@mkArtakMSFT mkArtakMSFT removed their assignment Apr 20, 2020
@mkArtakMSFT mkArtakMSFT added this to the Backlog milestone Apr 20, 2020
@arthurzaczek
Copy link

I followed these instructions and it worked for me. It would be really helpful, if this is documented in the debugging section.

I would suggest to add another browser profile called "Microsoft Edge with Dev-Profile" or something.

@SteveSandersonMS SteveSandersonMS added affected-most This issue impacts most of the customers enhancement This issue represents an ask for new feature or an enhancement to an existing one severity-nice-to-have This label is used by an internal tool labels Oct 6, 2020 — with ASP.NET Core Issue Ranking
@TanvirArjel
Copy link
Contributor

TanvirArjel commented Jan 3, 2021

@mkArtakMSFT Blazor WASM debugging should open in a new tab of the already opened window of the browser like ASP.NET Core MVC, Razor Pages app.

@javiercn javiercn added reevaluate We need to reevaluate the issue and make a decision about it feature-blazor-tooling Blazor specific tooling requests labels Apr 19, 2021
@TanayParikh TanayParikh modified the milestones: Backlog, 6.0.0 Oct 19, 2021
@TanayParikh TanayParikh added this to 6.0-Docs & Infra in ASP.NET Core Blazor & MVC 6.0 Oct 19, 2021
@TanayParikh
Copy link
Contributor

TanayParikh commented Oct 19, 2021

@guardrex could we please add some details to the debugging docs about how a new Edge/Chrome window with a separate "dev-profile" will be opened when debugging instead of opening a tab in your existing window?

This is pretty low priority though 😄

@TanayParikh TanayParikh moved this from 6.0-Docs & Infra to In Progress in ASP.NET Core Blazor & MVC 6.0 Oct 20, 2021
@ghost ghost added the Working label Oct 20, 2021
@guardrex
Copy link
Contributor

This is in progress on dotnet/AspNetCore.Docs#23564. Capt. Safia is called for review.

ASP.NET Core Blazor & MVC 6.0 automation moved this from In Progress to Done Oct 20, 2021
@ghost ghost added Done This issue has been fixed and removed Working labels Oct 20, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Nov 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affected-most This issue impacts most of the customers area-blazor Includes: Blazor, Razor Components Docs This issue tracks updating documentation Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-tooling Blazor specific tooling requests feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly reevaluate We need to reevaluate the issue and make a decision about it severity-nice-to-have This label is used by an internal tool
Projects
No open projects
Development

No branches or pull requests

9 participants