NEW 244559
No-op textContent replacement could be short-circuited, like in Chrome
https://bugs.webkit.org/show_bug.cgi?id=244559
Summary No-op textContent replacement could be short-circuited, like in Chrome
Ahmad Saleem
Reported 2022-08-30 15:57:07 PDT
Hi Team, While I was trying to triage old bug, I came across a test case, which is causing me difficult to post results in the browsers and selection is getting invalidating continuously and shuttering. Link - https://persistent.info/webkit/test-cases/selection-deletion.html Bug - https://bugs.webkit.org/show_bug.cgi?id=110682 << STEPS TO REPRODUCE >>> 1) Open Link 2) Try selecting "DOM" text and see "Selection will flash. BROWSER - Safari Technology Preview 152 and Safari 15.6.1 on macOS 12.5.1 3) Now try to open "Inspector" and select "DOM" and try to copy text within "DOM", you will not be able to copy and selection will get lost. << ACTUAL RESULTS >> Selection fails within browser view and in Web Inspector as well. << EXPECTED RESULT >> Let me copy my text.. :-) I though to create this bug in separate to make it easier to track and fix. Thanks!
Attachments
Alexey Proskuryakov
Comment 1 2022-08-30 18:59:39 PDT
The reason why this is happening in Safari and in Firefox is that the page replaces div.textContent every 100ms. The reason why this doesn't happen in Chrome is that this operation is short-circuited there, the Node isn't replaced when the text isn't changing. This optimization is not allowed per DOM Living Standard, but maybe the spec and WebKit can change if Chrome is getting away with it. Easy to observe with a test like this: <div id=div>aaa</div> e = document.getElementById("div").firstChild document.getElementById("div").textContent = "aaa"; e === document.getElementById("div").firstChild # true in Chrome, false in other browsers.
Karl Dubost
Comment 2 2022-08-30 19:28:18 PDT
> The textContent setter steps are to, if the given value is null, act as if it was the empty string instead, and then do as described below, switching on the interface this implements: > > … > > CharacterData > Replace data with node this, offset 0, count this’s length, and data the given value. in https://dom.spec.whatwg.org/#dom-node-textcontent and replace data in https://dom.spec.whatwg.org/#concept-cd-replace For the chrome optimization https://github.com/chromium/chromium/blob/924ec189cdfd33c8cee15d918f927afcb88d06db/third_party/blink/renderer/core/dom/node.cc#L2036-L2041 pointing to https://bugs.chromium.org/p/chromium/issues/detail?id=352836 as the source of the optimization.
Alexey Proskuryakov
Comment 3 2022-08-30 19:52:23 PDT
My steps in comment 1 aren't true to the original test case, which modifies document.querySelector("#dom").textContent. So this still seems like a Chrome bug per the spec? > Element > String replace all with the given value within this.
Karl Dubost
Comment 4 2022-08-30 20:06:28 PDT
yup, per spec. But I wonder if it could become an interesting optimization for all. Or if it has unintended consequences.
Anne van Kesteren
Comment 5 2022-08-31 06:48:52 PDT
Filed https://github.com/whatwg/dom/issues/1106 to discuss. Thanks for raising this Ahmad!
Darin Adler
Comment 6 2022-08-31 11:05:37 PDT
One irony here is that in Safari’s early days we had a many "do less work because nothing changed" optimizations; part of "growing up" as a web browser engine was removing those because they harmed interoperability. I hope we do all agree to make this optimization a standard thing; given our shared WebKit roots I wonder when/why WebKit and Chromium diverged on this point.
Radar WebKit Bug Importer
Comment 7 2022-09-06 15:58:16 PDT
Myles C. Maxfield
Comment 8 2022-09-07 22:22:53 PDT
Should we mark this bug as MOVED while https://github.com/whatwg/dom/issues/1106 is being discussed?
Alexey Proskuryakov
Comment 9 2022-09-08 10:26:41 PDT
We usually don't do this. I don't think that it's beneficial to hide it in RESOLVED state when it's an observable compatibility issue.
Ahmad Saleem
Comment 10 2022-09-20 06:09:06 PDT
I am not sure whether it is same bug or not but I came across another such case: https://jsfiddle.net/2kEZ7/1/show Try to copy the numbers / result from rotated cube / square: getBoundingClientRect().width of div element is: xxxx <----- can't select this text. It happens in Chrome Canary 108, Safari 16 while Firefox Nightly 107 does allow you to copy it while clicking on the line and double clicking but not when you are trying to double click on the value. Just wanted to share. Thanks!
Note You need to log in before you can comment on or make changes to this bug.