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. trey 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@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev

_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev