user-select and user-modify cause an unconditional repaint |
||||||||
Issue descriptionGoogle Chrome 54.0.2820.2 (Official Build) canary (64-bit) Revision eeda2a63b39ea71b74ec5497d8400ff7e81377c0-refs/branch-heads/2820@{#2} OS Mac OS X ComputedStyle::diffNeedsPaintInvalidationObject if (m_rareInheritedData.get() != other.m_rareInheritedData.get()) { if (m_rareInheritedData->userModify != other.m_rareInheritedData->userModify || m_rareInheritedData->userSelect != other.m_rareInheritedData->userSelect || m_rareInheritedData->m_imageRendering != other.m_rareInheritedData->m_imageRendering) return true; } it looks like maybe we want to call LayoutObject::setShouldInvalidateSelection() ?
,
Aug 9 2016
Here a test page to repro: changing user-select results in +10-11ms of paint time https://gist.github.com/valdrinkoshi/0e98ce7296939539043a2b67e0270edd
,
Aug 9 2016
Firefox doesn't clear or hide the selection when you change user-select, perhaps we should change our behavior to match?
,
Aug 10 2016
When would a developer want to change user-select on the fly?
,
Aug 10 2016
To temporarily disable a node e.g. for custom overlays, the content below them should not be selectable.
,
Aug 10 2016
*behind
,
Aug 10 2016
In that context, leaving the current selection when user-select changes seems reasonable to me.
,
Aug 10 2016
,
Feb 11 2017
,
Nov 16 2017
,
Nov 28 2017
,
Nov 28
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 28
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by esprehn@chromium.org
, Aug 9 2016