Closed Bug 339397 Opened 19 years ago Closed 3 years ago

Losing ownership of primary X selection does not collapse/remove selection

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 103564

People

(Reporter: pkasting, Unassigned)

Details

In X Windows: When there is a non-empty selection in Firefox, and a user makes a selection in another application (i.e. asserts ownership of the primary selection), Firefox does not collapse/remove its selection (de-highlight). This leads to user confusion as the application seems to be claiming that it's possible to middle-click-paste some text that is not, in fact, the primary selection.
The way to fix this is to write an implementation of nsIClipboardOwner that lives in content (not widget; widget doesn't know about clearing selections). I don't know if that means the .idl needs to move. When implemented, an instance of this nsIClipboardOwner can be passed in to SetData() when going through nsCopySupport, and will be responsible for clearing the selection later.
Assignee: selection → nobody
QA Contact: selection

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

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

Severity: normal → S4
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.