In a simple HTML document containing a comment before the HTML element and nested tables, when I select a substring and invoke -[WebHTMLView attributedSubstringFromRange:] I get a result which is offset by one character. Compile and run the attached test application (WebKitTest) then click the Test button. It does the following (v is an editable WebView *): [v moveToBeginningOfDocument: nil]; [v moveDown: nil]; [v selectWord: nil]; NSResponder<NSTextInput> *ti = [[self window] firstResponder]; // WebHTMLView NSLog(@"firstResponder %@ selectedRange %@", ti, NSStringFromRange([ti selectedRange])); NSLog(@"selected string: |%@|", [[ti attributedSubstringFromRange: [ti selectedRange]] string]); You'll see the first word ("selection") selected, and the range appears OK, but the output is: 2008-04-28 19:31:59.795 WebKitTest[55407:10b] firstResponder <WebHTMLView: 0x156a7c0> selectedRange {0, 9} 2008-04-28 19:31:59.797 WebKitTest[55407:10b] selected string: | selectio| The HTML file is attached separately for reference. If I remove the comment or one of the nested tables, the problem goes away; however, if I add text below the tables, it exhibits the problem as well. This problem was isolated from the spikesoft URL, which is a HTML disaster; the attached minimized version validates, however.
Created attachment 20879 [details] test application (Xcode project)
Created attachment 20880 [details] minimized test case
Tentatively confirming, although I couldn't actually verify this - Xcode 3.0 says that the project was saved with a newer version, and then fails to build id. But this sounds as a typical attributedSubstringFromRange bug.
Sorry about that; I've resaved the nib and project file in older formats and will attach them. I tested building on Tiger with Xcode 2.4.1, so it should work with that or later versions. Searching for attributedSubstringFromRange and following the trail of bugs I'm led to #5610 which hasn't been touched in 2.5 years. Is there a reason you haven't updated your patch after it was reviewed? Should I start with that patch, or is there other ongoing work I could potentially help with, if I want to see this bug fixed sooner rather than later? Thanks.
Created attachment 21156 [details] test application (Xcode 2.4 project)
The only reason is that it's hard - and often unclear what behavior would be correct, particularly when rendered text is significantly different than DOM (e.g. because of CSS transformations). There is no ongoing work in this area, as far as I know. There's a related patch in bug 15680 that should probably be landed though.
(In reply to comment #6) > The only reason is that it's hard - and often unclear what behavior would be > correct, particularly when rendered text is significantly different than DOM > (e.g. because of CSS transformations). Yeah, I see how that could be painful. A few of the offset-selection or extraneous-newline cases I've noticed so far seem to be relatively straightforward with no CSS or script-generated content involved. I have a list of other URLs to investigate (some have regressed since Safari 3.1.1, such as http://blog.michaeltrier.com/, although that one goes away when I disable CSS) but haven't tried to minimize any of them because I wanted to see what happened with this bug. Should I try to compile WebKit with the patch in bug 15680, and go from there? What information, code, test cases, etc. will help? I'm obviously not going to turn into a WebKit expert overnight but am certainly willing to invest some time into it.
I've just landed the patch from bug 15680, it actually fixes some cases of extraneous newline. Feel free to discuss the issues you'd like to work on IRC or on webkit-dev@lists.webkit.org mailing list to keep this bug for comments about the specific issue at hand here.
The description here, 'offset by one character' reminds me of 'Kupu 1.4.9: style application problems (most evident with the first letter of heading levels) in Safari 3.1.1 on Mac OS X 10.5.2 ' http://dev.plone.org/plone/ticket/8085 https://dev.plone.org/plone/attachment/ticket/8085/obvious%20problem%20with%20HTML%20%28before%20switching%20to%20HTML%20view%29.png demonstrates the symptoms; focus on the first letter of the words 'Background' and 'Outcomes'. If this WebKit bug 18794 is an explanation for http://dev.plone.org/plone/ticket/8085 then it will affect users of Kupu in a very annoying way, in which case I should plead for escalation. Thanks Graham
<rdar://problem/6105526>
Please, can you offer a progress report on this bug 18794 and/or on <rdar://problem/6105526>? Thanks Graham (I'm preparing to arrange Plone training for groups within our Centre, to include use of Kupu in Safari, and would like the experience to appear as professional as possible.) (For myself alone, I have a Safari 4 developer preview but have refrained from installing it.)
The whole history of this bug is in the above comments, there is no additional information. Help with fixing it would be welcome.