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.

Sign up for GitHub

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

Jump to bottom

Improving stopped indication ("breakpoint hit") for Web UI #100757

Closed
weinand opened this issue Jun 22, 2020 · 9 comments
Closed

Improving stopped indication ("breakpoint hit") for Web UI #100757

weinand opened this issue Jun 22, 2020 · 9 comments
Assignees
@isidorn
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues *out-of-scope Posted issue is not in scope of VS Code under-discussion Issue is under discussion for relevance, priority, approach web Issues related to running VSCode in the web
Milestone
On Deck

Comments

@weinand
Copy link
Contributor

weinand commented Jun 22, 2020

TBD
@weinand weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Jun 22, 2020
@weinand weinand added this to the June 2020 milestone Jun 22, 2020
@kieferrm kieferrm mentioned this issue Jun 22, 2020
Closed
57 tasks
@weinand weinand modified the milestones: June 2020, July 2020 Jun 29, 2020
@kieferrm kieferrm mentioned this issue Jul 10, 2020
Closed
49 tasks
@weinand weinand modified the milestones: July 2020, August 2020 Aug 6, 2020
This was referenced Aug 16, 2020
Closed
Closed
@weinand weinand modified the milestones: August 2020, On Deck Aug 31, 2020
@bpasero bpasero added the web Issues related to running VSCode in the web label Sep 3, 2020
@kieferrm kieferrm mentioned this issue Sep 14, 2020
Closed
41 tasks
@bpasero
Copy link
Member

bpasero commented Oct 14, 2020 •
edited
Loading

From: #99223

Investigate to use web notifications to indicate breakpoint hit

@bpasero bpasero mentioned this issue Oct 14, 2020
Closed
@weinand
Copy link
Contributor Author

weinand commented Oct 19, 2020

@isidorn yes, let's try "web notifications"...

@weinand weinand removed their assignment Oct 19, 2020
@isidorn
Copy link
Contributor

isidorn commented Oct 19, 2020

Makes sense, let me assign to October to experiment with web notifications.

@isidorn isidorn modified the milestones: On Deck, October 2020 Oct 19, 2020
@isidorn isidorn added the under-discussion Issue is under discussion for relevance, priority, approach label Oct 19, 2020
@isidorn
Copy link
Contributor

isidorn commented Oct 28, 2020

Did not have time for this, moving to November to experiment in debt week.

@isidorn isidorn modified the milestones: October 2020, November 2020 Oct 28, 2020
@isidorn
Copy link
Contributor

isidorn commented Nov 9, 2020

@bpasero do we maybe already use web notifications for something? I think not, but wanted to double check?
Also if we start using them, should I introduce a web notification service, or should this be part of the current notificationService just a new method?

@bpasero
Copy link
Member

bpasero commented Nov 9, 2020

@isidorn we don't use it currently and I don't think we should do this through a service because I feel web notifications should be the absolute exception and not the rule. Maybe do a local fix in your area to begin with.

One downside is that I think a browser will ask you for permissions to show notifications. Would be great is only appears when you debug and need it, not before.

@isidorn
Copy link
Contributor

isidorn commented Nov 9, 2020

@bpasero makes sense. I looked into the showNotifications API and I need a serviceWorker to call the showNotifications on it.
In our code base I only see that we register a service worker here. Is there some other common service worker which I could use or should I register a new one just for my use case?

p.s I tried out some sites and they ask you for permission as soon as you open the site. Though hopefully I could register the service worker lazily and avoid this...

@weinand weinand changed the title Investigate issues introduced by the Web UI stopped indication Improving stopped indication ("breakpoint hit") for Web UI Nov 11, 2020
@isidorn
Copy link
Contributor

isidorn commented Nov 11, 2020 •
edited
Loading

After discussions with @bpasero we came to the conclussion that a service worker is not something we can register and control in our web experience. Since the web notifications are not possible without a service worker, and web notifications alone do not justify an introduction of a service worker I am moving this to the Backlog.

Also the experience that opening VS Code UI the first thing we would request are notifications to use web notifications are not nice. And that is how notification API works in Chrome.

@isidorn isidorn modified the milestones: November 2020, Backlog Nov 11, 2020
@kieferrm kieferrm mentioned this issue Nov 16, 2020
Closed
65 tasks
@weinand weinand modified the milestones: Backlog, On Deck Nov 30, 2020
@kieferrm kieferrm mentioned this issue Dec 14, 2020
Closed
73 tasks
@kieferrm kieferrm mentioned this issue Feb 6, 2021
Closed
70 tasks
@kieferrm kieferrm mentioned this issue Mar 6, 2021
Closed
76 tasks
@kieferrm kieferrm mentioned this issue Apr 5, 2021
Closed
75 tasks
@isidorn
Copy link
Contributor

isidorn commented Aug 17, 2021

No action planned here, and I do not think there is something actionable to be done.
Thus closing

@isidorn isidorn closed this as completed Aug 17, 2021
@isidorn isidorn added the *out-of-scope Posted issue is not in scope of VS Code label Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@isidorn isidorn

Labels
debug Debug viewlet, configurations, breakpoints, adapter issues *out-of-scope Posted issue is not in scope of VS Code under-discussion Issue is under discussion for relevance, priority, approach web Issues related to running VSCode in the web
Projects
None yet
Milestone
On Deck
Development

No branches or pull requests
3 participants
@bpasero @weinand @isidorn