WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/99624320
>
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.
Top of Page
Format For Printing
XML
Clone This Bug