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)
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.
Reporter | ||
Comment 1•19 years ago
|
||
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.
Updated•15 years ago
|
Assignee: selection → nobody
QA Contact: selection
Comment 2•4 years ago
|
||
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
Updated•3 years ago
|
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.
Description
•