Bug 45686

Summary: Document in design mode should always have a selection range
Product: WebKit Reporter: webkit
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ahmad.saleem792, ap, bfulgham, rniwa, wenson_hsieh
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
TC
none
TC 2 none

webkit
Reported 2010-09-13 10:50:26 PDT
window.getSelection().rangeCount returns "0" (zero) for documents that have never been focused. Other browsers (FF and Opera) return "1", having an empty range available at the very start of the <body> contents. I'll include a simple TC to confirm it.
Attachments
TC (1.48 KB, text/html)
2010-09-13 10:53 PDT, webkit 		no flags
Details
TC 2 (1.70 KB, text/html)
2010-09-13 11:21 PDT, webkit 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
webkit
Comment 1 2010-09-13 10:53:17 PDT
Created attachment 67430 [details] TC
webkit
Comment 2 2010-09-13 11:21:25 PDT
Created attachment 67436 [details] TC 2 Adding a new TC to debug better the behavior on other browsers. It looks like in this case, they return the range that represents the selection when the browser will have the first focus (with the TAB key, for example).
Ahmad Saleem
Comment 3 2022-07-26 12:52:49 PDT
I am not clear on web-spec and what is expected but Safari 15.6 on macOS 12.5 and Chrome Canary 106 have same behavior across both test case while Firefox Nightly 104 differ. Safari 15.6 and Chrome Canary 106 show 'Number of ranges: 0' for both test cases. Although, Firefox Nightly shows 'Number of ranges: 1' for both test case but with different offset of 0 and 3 respectively in test cases. Just wanted to share updated results. Thanks!
Note You need to log in before you can comment on or make changes to this bug.