Bug 10883 - WebView - (void)setSelectedDOMRange fails in many circumstances
Summary: WebView - (void)setSelectedDOMRange fails in many circumstances
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 419.x
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-16 02:17 PDT by Robert Burns
Modified: 2014-10-14 12:45 PDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Burns 2006-09-16 02:17:01 PDT
When trying to insert a new element at the selectedDOMRange and that selectedDOMRange is collapsed the WebView will not accept a setSelectedDOMRange under several circumstances.

I've loaded content as both text/html and application/xml+xhtml.
I've tried inserting an empty textnode; a textnode with a single zero-width-space; a textnode with a single space (see bug 10881); and a textnode with several zero-width-spaces.

I've tried [webView replaceSelectionWithNode:],  [selectedDOMRange insertNode:], and a few others. I've tried normalizing (which seemed to have no effect at all). I'v tried selecting the inserted element with offset (0,0) and offset (0,1).

I've tried inline and block elements.
When working with application/xhtml+xml I've tried (DOMDocument createElement:] and(DOMDocument createElementNS:] .

All of these attempts have had the same results. The log shows a successful change of the ivar selectedRange, but when invoking setSelectedDOMRange on the webview it doesn't take.

Setting the selected DOMRange on Exiting elements work fine, but on the elements I create it fails. Without altering the selectedDOMRange to be inside newElement there's no way for the user to navigate with the keyboard into the element (bug report forthcoming).

Below is a code fragment that should help reproduce the bug and provide an illustration of the problem.


		if ([selectedRange collapsed]) {
			
//			textPlaceholder = [theDOMDocument createTextNode:@""];
			textPlaceholder = [theDOMDocument createTextNode:
				[NSString stringWithFormat:@"%c%c%c",
					8203, 8203, 8203]];
									
			[newElement appendChild:textPlaceholder];
			[selectedRange insertNode:newElement];

			NSLog(@"selectedRange is: %@", selectedRange);
			NSLog(@"the prior selected range is: %@", [webView selectedDOMRange]);
			NSLog(@"newElement is %@", newElement);
			
			[selectedRange setStart:textPlaceholder :1];
			[selectedRange setEnd:textPlaceholder :2];

//			[selectedRange setStart:newElement :0];
//			[selectedRange setEnd:newElement :1];

//			[selectedRange collapse:YES];

			[webView setSelectedDOMRange:selectedRange affinity:NSSelectionAffinityDownstream];

			NSLog(@"new selected range is: %@", selectedRange);

				NSLog(@"the selected range is: %@", [webView selectedDOMRange]);
			[webView display];

		} else {
			
			aFragment = [selectedRange cloneContents];
			NSLog(@"aFragment is %@", [aFragment textContent]);
			[newElement appendChild:aFragment];
			// [selectedRange surroundContents:newElement];
			[webView replaceSelectionWithNode:newElement];
		}
Comment 1 David Gatwood 2014-10-14 12:45:31 PDT
This is probably a dup of bug 15256 (or vice-versa, technically).  See patches attached to that bug.