Cannot copy text by painting after Node.js session in a new tab #5181

Closed
opened 2026-01-31 00:06:49 +00:00 by claunia · 6 comments
Owner

Originally created by @oturpe on GitHub (Nov 26, 2019).

Originally assigned to: @carlos-zamora on GitHub.

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.476]
Windows Terminal version (if applicable): 0.6.2951.0

Steps to reproduce

  1. Close Windows Terminal if it was already open
  2. Open Windows Terminal
  3. Open a new tab
  4. Execute the following minimal Node.js session:
    $ node
    > process.exit()
    $
    
  5. Try to paint some text on screen

Expected behavior

Text is painted and can be copied

Actual behavior

Nothing is painted

Further information

  1. This bug does not reproduce if the original tab is visited between opening the new tab and starting Node.
  2. I have also reproduced this with Python repl instead of Node.
  3. The Node.js session does not need to be interactive, running a script with node <filename> can also cause the problem.
  4. I can easily reproduce this bug anytime I wish, but it does not happen every time I try. I have not been able to discern if it depends on some hidden factor, or if I do things slightly differently.
  5. For what it is worth, the usual circumstances where I run into this include PowerShell (Core) 6.2.2 as the default tab and Ubuntu on WSL as the second tab. However I have seen this both when the second tab is the default shell, or Windows PowerShell.

Even though the conditions are quite specific, I actually run into this quite often when I need to run a single command under WSL and start Windows Terminal just for that.

The easy workaround is to switch tabs back and forth, which re-enables painting text.

Originally created by @oturpe on GitHub (Nov 26, 2019). Originally assigned to: @carlos-zamora on GitHub. # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18363.476] Windows Terminal version (if applicable): 0.6.2951.0 ``` # Steps to reproduce 1. Close Windows Terminal if it was already open 2. Open Windows Terminal 3. Open a new tab 4. Execute the following minimal Node.js session: ``` $ node > process.exit() $ ``` 5. Try to paint some text on screen # Expected behavior Text is painted and can be copied # Actual behavior Nothing is painted # Further information 1. This bug does not reproduce if the original tab is visited between opening the new tab and starting Node. 2. I have also reproduced this with Python repl instead of Node. 2. The Node.js session does not need to be interactive, running a script with `node <filename>` can also cause the problem. 3. I can easily reproduce this bug anytime I wish, but it does not happen every time I try. I have not been able to discern if it depends on some hidden factor, or if I do things slightly differently. 4. For what it is worth, the usual circumstances where I run into this include PowerShell (Core) 6.2.2 as the default tab and Ubuntu on WSL as the second tab. However I have seen this both when the second tab is the default shell, or Windows PowerShell. Even though the conditions are quite specific, I actually run into this quite often when I need to run a single command under WSL and start Windows Terminal just for that. The easy workaround is to switch tabs back and forth, which re-enables painting text.
claunia added the Resolution-Duplicate label 2026-01-31 00:06:49 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Nov 30, 2019):

By "painting" do you mean "selecting"?

@DHowett-MSFT commented on GitHub (Nov 30, 2019): By "painting" do you mean "selecting"?
Author
Owner

@oturpe commented on GitHub (Nov 30, 2019):

By "painting" do you mean "selecting"?

Yes, like this:

image

@oturpe commented on GitHub (Nov 30, 2019): > > > By "painting" do you mean "selecting"? Yes, like this: ![image](https://user-images.githubusercontent.com/5121186/69905903-79215700-13c3-11ea-9525-83b92911ce9c.png)
Author
Owner

@zadjii-msft commented on GitHub (Dec 2, 2019):

I can't seem to get this to repro:
image

There's maybe a chance this was actually solved in v0.7 - @oturpe could you try updating and see if it still happens?

Is there any chance you have a padding set for the WSL profile, and you're trying to select in the padding region?

@zadjii-msft commented on GitHub (Dec 2, 2019): I can't seem to get this to repro: ![image](https://user-images.githubusercontent.com/18356694/69968874-f8587d00-14e0-11ea-9321-8f8b40e811bb.png) There's maybe a chance this was actually solved in v0.7 - @oturpe could you try updating and see if it still happens? Is there any chance you have a `padding` set for the WSL profile, and you're trying to select in the padding region?
Author
Owner

@oturpe commented on GitHub (Dec 2, 2019):

Hello @zadjii-msft,

Thanks to Microsoft Store, my Windows Terminal has updated to 0.7.3291.0, but the problem remains.

Padding it set to "0, 0, 0, 0", so I suppose that is not related.

However, while I was checking the situation with the new version, I noticed the following:

  1. Sometimes I can run the test sequence multiple times without reproduction. I think the longest sequecence of successful tries was ~10. So, perhaps this does not reproduce quite as often as I implied earlier. But, I can still confidently reproduce this on my machine, by just running the instructions over and over again.
  2. The part about running Node (or anything) is not a necessary condition: I noticed that sometimes text cannot be selected from a freshly opened tab that has not been used for anything yet. I guess that part ended up in the initial report only because I had not tried to selecting anything from an unused tab.
@oturpe commented on GitHub (Dec 2, 2019): Hello @zadjii-msft, Thanks to Microsoft Store, my Windows Terminal has updated to 0.7.3291.0, but the problem remains. Padding it set to `"0, 0, 0, 0"`, so I suppose that is not related. However, while I was checking the situation with the new version, I noticed the following: 1. Sometimes I can run the test sequence multiple times without reproduction. I think the longest sequecence of successful tries was ~10. So, perhaps this does not reproduce quite as often as I implied earlier. But, I can still confidently reproduce this on my machine, by just running the instructions over and over again. 2. The part about running Node (or anything) is not a necessary condition: I noticed that sometimes text cannot be selected from a freshly opened tab that has not been used for anything yet. I guess that part ended up in the initial report only because I had not tried to selecting anything from an unused tab.
Author
Owner

@carlos-zamora commented on GitHub (Dec 2, 2019):

/dup of #1038

@carlos-zamora commented on GitHub (Dec 2, 2019): /dup of #1038
Author
Owner

@ghost commented on GitHub (Dec 2, 2019):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Dec 2, 2019): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5181