<table><tr><td style="">davidedmundson added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D12373">View Revision</a></tr></table><br /><div><div><p>We have two settings:<br />
The first, when the X selection owner gets cleared, replaces the clipboard with the top entry<br />
This one when the X selection owner gets cleared, deletes the top entry in the UI.</p>

<p>Both default to on, which together makes no sense. We're replacing the clipboard and then immediately deleting that same entry.</p>

<p>At a minimum it's a conflicting option that needs to be handled properly.</p>

<p>Even then I'm not 100% convinced.</p>

<p>If a client copies two pieces of sensitive data and then calls clear you've not solved anything.</p>

<p>But more importantly if another X client clears the selection owner even if it doesn't own the previous data, you're just deleting random things. <br />
Something we know happens a lot which is why we have that preventEmpty situation on by default.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item"></li>
</ul>

<p>Personally I think the smarter solution (though I understand it's harder to get it in) would be to have keepassx put some hint in the mimeData  x-kde-clipboard-manager-skip-this: true   and then have klipper completely ignore the entry when it gets copied rather than trying to solve a problem after it's already happened.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12373">https://phabricator.kde.org/D12373</a></div></div><br /><div><strong>To: </strong>hoffmannrobert<br /><strong>Cc: </strong>broulik, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>