4 ms·
The only copy visible fix was afaik reject in the bug tracker because you could switch the visibility on and off for a short time (<1s). The don't allow change
by bpfrh 7y ago
The only copy visible fix was afaik reject in the bug tracker because you could switch the visibility on and off for a short time (<1s).
The don't allow changes to selection would mean if you mark something on a website and use a button to change it (change to a link for example) you can't do that anymore.
The proposed fix would be either easily circumvented or/and would mean a high risk of breaking working sites.
If you read the bug section the last comment explains why the proposed fixe are a bad idea.
- yellowapple 7y ago> The proposed fix would be either easily circumvented or/and would mean a high risk of breaking working sites. It wouldn't be harder to circumvent if changing the text (including the visibility thereof) between the start and end of the selection caused an automatic deselection. It shouldn't break any sites, either, unless those sites are doing fishy things or are already poorly designed (which - again - would warrant the torches and salt).
- bpfrh 7y agoSorry for the late reply. That would mean the following would not work: selecting text-->making it bold(via button)-->making it underlined(via button)-->making it to a link(via button). There are valid use cases for selections and manipulations. I think the only way to work against such a thing would be to display the selected text in a tooltip like window, like another user described.
- yellowapple 7y agoThe web app could maintain its own start and end points for the selection (independent of what the browser deems "selected") and apply those operations to the text within that internally-defined range. None of those things affect visibility, though, nor do they change the actual content (just the styling/appearance), so the "deselect on visibility or content change" approach wouldn't impact that at all anyway.