613280 - Cannot copy result text in console

Status: VERIFIED FIXED

(DevTools :: General, defect, P2)

Description

[Jeff Balogh (:jbalogh)]

The result of js expressions are clickable objects, and I can't find a way to copy the text.  Right-click shows the context menu for the whole console. If I try to start a selection before the result it's still ignored.

For example, 2 cannot be selected here:

> 1 + 1
2

Comment 1

[Maniac Vlad Florin (:vladmaniac)]

Is this a regression from bug 587617?

Comment 2

[Mihai Sucan [:msucan]]

Florin: bug 587617 fixed an issue with text selection and copying, on Linux. I doubt it caused this regression.

Comment 3

[Kevin Dangoor]

mass change: filter on PRIORITYSETTING

Comment 4

[Mihai Sucan [:msucan]]

Attachment: proposed patch

Proposed patch. This fixes a minor style issue that prevents users from selecting jsterm output and copying the text. I believe this is a regression caused by some previous work on jsterm code.

Included is a test case that checks for this specific issue.

Comment 5

[Mihai Sucan [:msucan]]

Asking for blocking2.0+: this bug affects all users of the Web Console, on all operating systems. An important functionality (select > copy) is not working as expected.

Comment 6

[Patrick Walton (:pcwalton)]

Comment on attachment 493512 [details] [diff] [review]
proposed patch

>diff --git a/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_613280_jsterm_copy.js b/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_613280_jsterm_copy.js
>new file mode 100644
>--- /dev/null
>+++ b/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_613280_jsterm_copy.js
>+    make_selection();
>+  }
>+  else {
>+    make_selection();
>+  }

Move make_selection after the if statement perhaps?

The patch doesn't apply in the makefile, but looks good to me otherwise. f+!

Comment 7

[Mihai Sucan [:msucan]]

Attachment: updated patch

Updated patch based on your feedback. Yeah, I forgot to do that. The test started from a different iteration. Thanks for the feedback+!

Asking for review.

Comment 8

[Mihai Sucan [:msucan]]

The current situation here:

- this patch no longer applies cleanly / works as intended, because the code changed a lot with the checkin of part 1 from bug 605621.

- this bug is going to (should) be fixed by part 2 from bug 605621.

- currently, part 1 landed, but not part 2, which means users cannot copy anything from the Web Console, not just jsterm results. The situation is now worse than initially reported in this bug.

- this patch should only hold the mochitest, once part 2 of bug 605621 lands.

Marking 605621 as a dependency.

Comment 9

[Rob Campbell [:rc] (:robcee)]

should be fixed by landing of bug 605621.

Comment 10

[Rob Campbell [:rc] (:robcee)]

reopening. Looks like there's a test to land with this.

Comment 11

[Patrick Walton (:pcwalton)]

Removing hardblocker since this is now fixed, making this bug tests-only.

Comment 12

[Mihai Sucan [:msucan]]

Attachment: mochitest only

Updated the patch. It only holds the mochitest now, rebased to work with the latest Web Console changes.

Comment 13

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 505438 [details] [diff] [review]
mochitest only

looks good.

Comment 14

[Jonathan Watt [:jwatt]]

Pushed http://hg.mozilla.org/mozilla-central/rev/6662101e4dbf

Comment 15

[Rob Campbell [:rc] (:robcee)]

marking fixed. Thanks for the checkin.

Comment 16

[[:Aleksej]]

Reproduced with Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101123 Firefox/4.0b8pre

Verified fixed with 4.0 beta 11 build 3 — Mozilla/5.0 (X11; Linux i686; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 (the timestamp and the number are copied)