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

text-selection is lost when data is written outside of the viewport #468

Closed
foot opened this issue Jan 11, 2017 · 4 comments
Closed

text-selection is lost when data is written outside of the viewport #468

foot opened this issue Jan 11, 2017 · 4 comments
Assignees
Labels
type/enhancement Features or improvements to existing features
Milestone

Comments

@foot
Copy link

foot commented Jan 11, 2017

This is sort of a sub-case of #318 that feels like it could be an easier fix.

Perhaps we could avoid redrawing the terminal if the updated lines fall outside the current viewport. I'm not sure if this would be an easy fix so please close this issue if time would be better spent pursuing a proper fix for #318 etc.

Big use case here is scrolling back through tail -f'd logs and trying to copy and paste them.

Details

  • Browser and browser version: Chrome Version 55.0.2883.95 (64-bit)
  • OS version: OSX 10.11.6 (15G1108)
  • xterm.js version: 2.2.3

Steps to reproduce

  1. while true; do echo 1; sleep 1; done
  2. Wait for echos to hit the bottom of the term.
  3. Scroll back up, so that terminal appears fairly static (new echos are coming in below the last visible line).
  4. Try and select text - selection is lost on next echo

Cheers!

@Tyriar
Copy link
Member

Tyriar commented Jan 11, 2017

Great idea @foot! Should be an easy fix and a great optimization for when you're looking at scrollback. I mention something similar in the linkify proposal #455 where I want us to shift rows up instead of redrawing the entire viewport when there is a new row. I'll keep this open to make sure this case is handled 😃

@Tyriar Tyriar added the type/enhancement Features or improvements to existing features label Jan 11, 2017
@SimonHui931208
Copy link

When can this problem be solved?I had tried to sovle it by adding other MouseEvents in my local codes. Firstly, I add the actual row number on each div,which is in the function '_refresh' that in the file of Renderer.ts,as follows:

this._terminal.children[y].setAttribute("row", row);
this._terminal.children[y].innerHTML = out;

Then I use the API document.caretRangeFromPoint to get the Range Informations when mousedown and mouseup. Then, the Terminal.lines._array had cached will to be used to select the actual Range which user chooses.Finally,window.getSelection.addRange(Range).

Howerver, it is so difficult.The selection will disappear when I user the scrollDisp(1). :(

@Tyriar
Copy link
Member

Tyriar commented Apr 1, 2017

@SimonHui931208 selection is going to be completely rewritten soon in #207 which should fix this by managing what is selected ourselves, rather than trying to bend standard web selection to our will.

@Tyriar
Copy link
Member

Tyriar commented Jun 9, 2017

Fixed in #670

@Tyriar Tyriar closed this as completed Jun 9, 2017
@Tyriar Tyriar added this to the 2.8.0 milestone Jun 9, 2017
@Tyriar Tyriar self-assigned this Jun 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement Features or improvements to existing features
Projects
None yet
Development

No branches or pull requests

3 participants