See http://hoeben.net/files/webkit/repro7156.html for a simple repro document. Clicking the anchor opens the specified uri. This makes it tricky to select the link in order to manipulte it (eg removing the link, changing the linked url). Anchors should be disabled in designmode.

Created attachment 6482 [details] Testcase Added Aldo's testcase to the bug itself.

( (In reply to comment #1) > See http://hoeben.net/files/webkit/repro7156.html for a simple repro document. > > Clicking the anchor opens the specified uri. This makes it tricky to select the > link in order to manipulte it (eg removing the link, changing the linked url). > > Anchors should be disabled in designmode. > To match Firefox & Internet Explorer's behavior, you should be able to navigate to the link by pressing ctrl-clicking (or the Mac equivalent) it.

This is very easy to fix if someone wants to take a shot at it. You just have to patch the defaultEventHandler for the anchorelement and check to see if the link is editable. If so, do the right thing. You should be able to just check the links user-modify style, assuming the concept of making a whole WebView editable has been fixed to properly adjust all the style property values for elements. (It probably hasn't though.)

Created attachment 8257 [details] Patch with simple fix Links in editable areas will not activate or perform a navigation change (on par with WinIE and Firefox.) To visit the link you can shift-click. Manual test added. * css/cssstyleselector.cpp: (WebCore::CSSStyleSelector::adjustRenderStyle): * html/html_inlineimpl.cpp: (WebCore::HTMLAnchorElement::defaultEventHandler): (WebCore::HTMLAnchorElement::setActive): * html/html_inlineimpl.h: * manual-tests/contenteditable-link.html: Added. * page/FrameView.cpp: (WebCore::selectCursor): A more complex fix to allow editing of the href is being talked about, but this lets us behave like IE and Firefox.

Comment on attachment 8257 [details] Patch with simple fix I understand all of this except for the HTMLAnchorElement::setActive part. Why doesn't it need a check for the shift key? r=me, in any case

Is there a way to change the current event in setActive? If so I agree, checking for the shift key there would be correct.

That should read: Is there a way to check the current event...

Landed in r14346.

Not sure if this is what was meant by >A more complex fix to allow editing of the href is being talked about, >but this lets us behave like IE and Firefox. but, it does not appear that it is possible to select a portion of a link now. Is the click event being "eaten" by the new code? You can start a selection from outside the link and continue into it, but you cannot start a selection *in* the link itself.

In the test case attached to this bug that is not the case. The TinyMCE example page seems to have a event listener that they do not allow to propagate, preventing the click (this is mentioned in bug 8817).