103564 - primary selection never cleared when text deselected

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Laszlo Domoszlai]

If I select something and after I click somewhere else to delete last selection,
the selection is deleted in Mozilla, but other programs still know it.
I think, the selection owner should be deleted.

Comment 1

[Boris Zbarsky [:bzbarsky]]

See the behavior of xterm in these circumstances... we act very similarly, no?

I recommend invalid on this one.

Comment 2

[Laszlo Domoszlai]

No, the copy acts only between xterms.
Try it please:
 1.select a word in xterm
 2.deslect
 3.copy an other xterm window
 4.copy a gnome terminal(for example)

3 works, 4 doesn't work
So, I think xterm doesn't use the X selection mechanism in this case.

 

Comment 3

[Boris Zbarsky [:bzbarsky]]

For more fun:

 1.select a word in gnome-terminal
 2.deslect
 3.paste to another gnome-terminal window

It pastes.

 4.paste to an xterm

It pastes.

 5.paste to Mozilla

It pastes.

xterm clears PRIMARY but leaves the selection in cut buffer 0.  Moz and
gnome-terminal don't clear PRIMARY, looks like.  Also looks like gnome-terminal
does not read cut buffer 0.  There seem to be three bugs here:

1)  gnome-terminal should read cut buffer 0
2)  Mozilla should put its selection in cut buffer 0 (bug 37057)
3)  Mozilla and gnome-terminal do not clear PRIMARY on deselect (this bug)
Confirming this bug 

Comment 4

[sairuh (rarely reading bugmail)]

selection?

Comment 5

[Laszlo Domoszlai]

Attachment: clear primary selection

I have made this small patch fixing this bug. It add a new
method to nsIClipboard that can set the selection owner to null that will 
emit a clear_selection signal and that will do the rest of the job.
I think :) 
I wonder if you could review this patch.

Comment 6

[anthonyd]

akkana, can you try this patch out please on unix?

Comment 7

[Akkana Peck]

With the patch, I see this:
- Select in mozilla
- Paste to rxvt (selection pastes as expected)
- Click in mozilla window (visible selection disappears)
- Paste to rxvt (it pastes something else entirely -- the last thing that was
selected before I made the selection in mozilla).

This is definitely not what I expected -- I expected it to paste the thing that
had been selected in mozilla (since that's what would have happened if I'd
selected in another rxvt window, or emacs, or previously in mozilla, or in most
other apps I use) or to paste nothing (which is what happens if I click-deselect
in a few apps, e.g. tkirc.

Note, if I do the pastes to a text field in mozilla rather than to rxvt, then I
get the tkirc behavior (selection is cleared, nothing is pasted) on the second
paste.  So that's better, but if it screws up rxvt and other terminal apps it's
going to be fairly annoying and noticable.

If we're going to stop asserting the selection, then we should clear it and not
let it revert to something else.  Personally, I prefer the existing behavior, of
keeping the selection rather than clearing it, since with apps that clear the 
selection it's very easy to lose the selection accidentally.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> it pastes something else entirely

This is due to bug 37057

> if I do the pastes to a text field in mozilla rather than to rxvt

This is due to bug 63419

Could we possibly fix all three in one fell swoop?

Comment 9

[Akkana Peck]

This is closely tied in with those two Pavlov bugs (and various other related X
selection issues) and rightfully belongs to him.  We shouldn't fix this before
those are fixed, since things are fine now and this would make them worse.

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 153070 has been marked as a duplicate of this bug. ***

Comment 11

[Jamie Zawinski]

This bug is not dependent on bug 37057 or on bug 63419 -- those bugs both say
"please support CUT_BUFFER0".  Mozilla should not support cut buffers at all:
cut buffers have been officially obsolete since X10!  Newly written code should
only use Selections.  The only reason that anyone supports cut buffers is
because for years, the default settings of xterm were backwards.

*This* bug simply says, "when text is no longer selected, Mozilla should disown
the PRIMARY selection."  This should be done regardless of CUT_BUFFER behavior.
 If you don't have selected text, you're not supposed to hold the PRIMARY
selection any more.

See http://www.jwz.org/doc/x-cut-and-paste.html for details.

Comment 12

[Zack Weinberg (:zwol)]

I don't have an opinion on Jamie's conclusion in an abstract user interface
design sort of way, but I most definitely do disagree with them on the grounds
that my fingers are wired to expect the other behavior.

PRIMARY should be "sticky" - it should stay asserted after the visible selection
is gone, unless the visible selection is gone because some other client asserted
PRIMARY.  This is the way classic X apps have always worked, and my fingers are
very unhappy that authors of modern X apps are not implementing that behavior.

Mozilla compounds the problem by not dropping the visible selection when some
other client asserts PRIMARY, but that's an orthogonal bug (I have just filed
bug #263875 for this).

Comment 13

[Boris Zbarsky [:bzbarsky]]

> This is the way classic X apps have always worked

Name such an app, please?  Make sure it's actually using PRIMARY and not
CUT_BUFFER0, first.  See comment 3.

Comment 14

[Zack Weinberg (:zwol)]

All of them.  Really.  Try it yourself.

I shall not investigate CUT_BUFFER0 vs PRIMARY, because it doesn't matter what
the implementation details of the old user-visible behavior were.  What matters
is that the old user-visible behavior was that middle-mouse paste would paste
the most recently selected thing EVEN IF that thing was no longer visibly
selected.  My fingers don't care what's going on under the hood, they care that
the user-visible behavior stays the same.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Try it yourself.

I did.  At length.  See comment 3. 

> because it doesn't matter what the implementation details of the old
> user-visible behavior were.

It does if the old behavior was using functionality that's now deprecated and
hence in danger of being removed (CUT_BUFFER0).  Which means that it can no
longer be used.  Which means that another solution is needed.

Please take this up with the X people (who deprecated CUT_BUFFER0), not with
people trying to write apps on the platform.

Comment 16

[Zack Weinberg (:zwol)]

> It does if the old behavior was using functionality that's now deprecated and
> hence in danger of being removed (CUT_BUFFER0).  Which means that it can no
> longer be used.  Which means that another solution is needed.

"Don't clear PRIMARY when you clear the visible selection, unless the visible
selection is being cleared because PRIMARY has changed" seems like a perfectly
sensible solution to me.

Comment 17

[Jamie Zawinski]

I think it would be reasonable behavior for Mozilla to continue holding the
PRIMARY selection when no text was highlighted, so long as no other app had
asserted PRIMARY.  I think that's all Zack is asking for.

(There is no need to use CUT_BUFFER0 to make this work; you can make it work
with PRIMARY.  I strongly believe that CUT_BUFFER0 should never be used and that
bug 37057 and bug 63419 should not be "fixed".)

However, it's really, really bad that Mozilla leaves text highlighted when it is
no longer the PRIMARY owner.  That's just insanely confusing.  (And I think that
on this part we've all been in agreement on that fact since this bug was
reported three long years ago.)

Comment 18

[Boris Zbarsky [:bzbarsky]]

Yeah, no one's disagreeing much about clearing selection when PRIMARY is lost. 
The problem is that the selection code is so Windows-centric (eg we can have
multiple selections within Mozilla itself, all at once!) and no one has stepped
up to fix that issue (which is covered by other bugs in any case).

Comment 19

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.