CSS Highlights API bug when deleting and adding ranges
Categories
(Core :: DOM: Selection, defect)
Tracking
()
People
(Reporter: kizmarh, Assigned: jjaschke)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
To reproduce (testing in 123.0a1 (2023-12-31) (64-bit)):
- Go to https://codepen.io/kizu/pen/WNmQrBW?editors=1010 (or open an attached .html)
- Click the button.
- Blur the button by clicking elsewhere.
What happened:
- After step 2: the first word is fully highlighted, the second half of the second word is highlighted.
- After step 3: the second word is not highlighted, the first word is fully highlighted.
What is expected:
- There should be no visual changes: removing a range, then adding the same range should not have any impact. Safari and Chrome seem to work the same.
Updated•1 year ago
|
Assignee | ||
Comment 1•1 year ago
|
||
Hi Roman,
Thank you for your report. I’ll investigate!
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 2•1 year ago
|
||
Ranges inside of a Selection
are expected to be sorted by their start point by the painting algorithms. Also, StaticRange
s, which previously were not part of Selection
, need to be considered for painting based on their IsValid()
status.
This is now added by introducing a second array for invalid static ranges and an additional re-ordering method which needs to be called before paint that moves ranges in between.
A potential change in range endpoints can be determined by observing the Document
s generation and by adding a flag that's set to true in Selection::NotifySelectionObservers()
.
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Reproducible on a 2024-01-19 Nightly build on macOS 12.
Verified as fixed on Firefox 124.0b2 and Nightly 125.0a1 on macOS 12, Windows 10, Ubuntu 22.
Description
•