New issue
Advanced search Search tips

Issue 836939 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

hterm: Firefox reports NS_ERROR_FAILURE when try to copy to clipboard

Reported by mirgajaz...@gmail.com, Apr 25 2018

Issue description

Chrome Version       : 64.0.3282.167
URLs (if applicable) :
Other browsers tested:
       Safari: not tested
    Firefox: FAIL 59.0.2 (windows 7, windows 10, ubuntu 16)
       Edge: PASS 40.15063.674.0

What steps will reproduce the problem?
I don't have simple steps. Basically use hterm in a web page displayed in firefox. Have some text in the <div> given to TerminalEmulator.decorate(). Have ctrl-c-copy and ctrl-v-paste set to true in PreferenceManager. Select some text using the mouse and observe nothing lands in the clipboard (try pasting into notepad or wordpad), and NS_ERROR_FAILURE appears in firefox javascript console.

What is the expected result?
When I use ctrl+c to copy text highlighted inside the hterm pane, the selected text should be copied into the clipboard and thus available when I use ctrl+v to paste (either into the hterm pane or into other applications).

What happens instead?
Firefox does not copy anything into the clipboard. Javascript console shows NS_ERROR_FAILURE (no other text appears, just NS_ERROR_FAILURE) with a line number that points to the function hterm.Terminal.prototype.copyStringToClipboard() at the line:
selection.selectAllChildren(copySource);

Please provide any additional information below. Attach a screenshot if
possible.
I searched around and found known issue in mozilla bug database that seems to match this problem. It's 3 years old, so it's unlikely to get fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1178676

I searched around for other ways I could select text (which is what the selectAllChildren() is doing) and found that I could replace that one line of code with this code block:

    var range = this.document_.createRange();
    range.selectNodeContents(copySource);
    selection.removeAllRanges();
    selection.addRange(range);

This eliminated the firefox exception and successfully copies to clipboard in firefox (tested on windows 7, windows 10, ubuntu 16), chrome (tested on windows 7, windows 10), and edge. I am not super expert, so maybe this is or is not the right solution. Just wanted to provide something as a starting point.
 

Comment 1 Deleted

Comment 2 Deleted

I was able to cook up a standalone html file that exhibits the issue when you use firefox to display it. So now I have steps to reproduce:
1. Run firefox.
2. Use ctrl+shift+j to open javascript console.
3. Display attached htermExperiment.html file (co-locate hterm_all.js in same directory). Should see "hello world" displayed.
4. Use mouse to highlight some/all of tghe "hello world" text. Observer NS_ERROR_FAILURE in javascript console. Observe selection is not in the clipboard.
htermExperiment.html
1.4 KB View Download

Comment 4 by vapier@chromium.org, Apr 27 2018

you probably want to set use-default-window-copy to true

copy & paste on the open web is tricky
Thanks for the idea. But setting use-default-window-copy to true did not change the behavior. Still get the NS_ERROR_FAILURE.
Cc: rbasuvula@chromium.org
 Issue 884808  has been merged into this issue.
Owner: vapier@chromium.org
Status: Started (was: Unconfirmed)
i'm going to swallow the error as i haven't been able to find a workaround:
  https://chromium-review.googlesource.com/1252412
Project Member

Comment 8 by bugdroid1@chromium.org, Oct 3

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/4968d49bae7b8678dfb793453b507e1adec20c71

commit 4968d49bae7b8678dfb793453b507e1adec20c71
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Oct 03 22:32:59 2018

hterm: workaround FF bug with selectAllChildren

In some situations, it looks like FF throws NS_ERROR_FAILURE when we
call Selection.selectAllChildren().  Add a try/catch block to prevent
the temporary node being stuck in the DOM.

Going by the upstream report, there doesn't seem to be a way for us
to workaround the bug.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178676
Bug:  836939 
Change-Id: Id0f484f5b7e1e2f3370895cbc94074690a4aad03
Reviewed-on: https://chromium-review.googlesource.com/c/1252412
Reviewed-by: Vitaliy Shipitsyn <vsh@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/4968d49bae7b8678dfb793453b507e1adec20c71/hterm/js/hterm_terminal.js

Status: Fixed (was: Started)
should be fixed in hterm-1.82+ and nassh-0.9+

Sign in to add a comment