[webkit-dev] Programmatically Selecting a DOMRange in a WebView and New WebKit-Related Bug in Apple Mail

Trey Matteson trey at usa.net
Wed Jul 5 14:59:52 PDT 2006

Making semantic API changes in a minor release is dangerous, because  
dependent apps don't retest and reship at those points the way they  
semi-expect to for a major release.  I'd expect that as the number of  
webkit client apps grows, the cost of breaking 3rd party apps will  
weigh more heavily against browser compatibility benefits for  
Safari.  Sometimes the safer approach may be to enable such changes  
only within Safari (or other apps that opt in), but leave the WebKit  
API more stable until a major release point.  In the AppKit we used  
to enable this sort of fix dynamically, based on what version of the  
framework the app was linked against.

I'm not saying that this particular Mail image editing regression is  
such a terrible bug that this WebKit fix shouldn't have been made,  
but more just tossing out a general point.


On Jul 5, 2006, at 1:26 PM, Timothy Hatcher wrote:

> You are unable to select images like Mail because of a recent  
> change in WebKit's user agent style-sheet. We now add "-khtml-user- 
> select: element" to images and other elements to improve normal  
> browsing and editing. This change was introduced in 10.4.6.
> We also fixed khtml-user-select: none to have the following  
> additional behavior (that matches Firefox's implementation of the  
> property as well)
>  (a) If you mouse down (or click, double click, triple click)  
> inside a "none" region, the selection should not be cleared or changed
>  (b) If you drag from within a "none" region out to a selectable  
> region, no selection should be changed or started.
> This change added a new value to khtml-user-select called "element"  
> that is used for any object that should have the behavior of (a)  
> and (b) above (but that is selectable aside from that).  This  
> includes images, links, buttons, and so on. This fixed the big  
> contenteditable issue and selection is no longer cleared now when  
> you click on these controls (or on links). This behavior matches  
> other browsers.
> You will need to add a author style-sheet that overrides -khtml- 
> user-select this like:
> img {
>     -khtml-user-select: auto;
> }
> For the other bugs you mention you should file individual bug  
> reports at http://bugreport.apple.com
> — Timothy Hatcher
> On Jul 5, 2006, at 1:02 PM, Steven Schuldt wrote:
>> All:
>> I've been unable to programmatically select a DOMRange in a  
>> WebView (this on Mac OS X 10.4.7).  I'm trying to emulate the  
>> behavior one can see in an editable WebView such as in Mail.app's  
>> compose window where the user can click on an image (to begin a  
>> drag for example) and the WebView immediately selects the image  
>> prior to the drag action.  The simple case fails:
>> 	DOMRange *range = [myWebView editableDOMRangeForPoint: [[self  
>> window] convertScreenToBase:[NSEvent mouseLocation]]];	
>> 	[range collapse:NO];
>> 	[ myWebView setSelectedDOMRange:range affinity:[myWebView  
>> selectionAffinity]];
>> And worse, there appears to be a bug (or an undocumented API  
>> change) whereby the WebEditingDelegate method:
>> - (BOOL)webView:(WebView *)webView shouldChangeSelectedDOMRange: 
>> (DOMRange *)currentRange toDOMRange:(DOMRange *)proposedRange  
>> affinity:(NSSelectionAffinity)selectionAffinity stillSelecting: 
>> (BOOL)flag;
>> WebEditingDelegate method is no longer called.
>> Also: The latest changes to WebKit's editing capabilities as Apple  
>> now distributes them with 10.4.7 have broken something fundamental  
>> in DOMRange selection.  Whatever hack Apple used to use to perform  
>> the above magic I'm trying to emulate has itself broken now.  To  
>> see the bug, drag a few small images into Mail.app.  Now try to  
>> move them around by dragging them to rearrange their order.  Note  
>> how Mail.app programmatically selects two images instead of just  
>> the one you're dragging.
>> Any pointers appreciated.  Thanks!
>> Steven
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at opendarwin.org
>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060705/ae47ab21/attachment.html

More information about the webkit-dev mailing list