[Webkit-unassigned] [Bug 60529] Programmatically set selection should not have direction on Mac

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=60529





--- Comment #45 from Wyatt Carss <wcarss at chromium.org>  2011-08-04 15:35:30 PST ---
(From update of attachment 102989)
View in context: https://bugs.webkit.org/attachment.cgi?id=102989&action=review

The spreadsheet linked above has a list of all of the spots where directionality is preserved, on the far left, with justification included where reasonable.

> LayoutTests/platform/chromium-linux/editing/pasteboard/subframe-dragndrop-1-expected.txt:2
> +EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification

These rebaselines seem to be from the no-argument VisibleSelection constructor; when a frame is constructed, it makes an empty frame selection which has an empty visible selection, which is directionless. It then (pretty immediately) calls setSelection, in a spot where we make a new selection which is optionally directional or not depending on the platform. If the new selection is directional, and the old one isn't, this delegate occurs. 

I think that the best solution would be to somehow have the no-arg VisibleSelection constructor (and all others, for that matter) immediately take on the correct value for isDirectional, but VisibleSelection only has access to the editingBehavior through pos->document->frame->behavior (which by the way, uses frame->settings to find the behavior, which seems silly), and frame isn't guaranteed to be accessible. So, this method presently causes a bunch of crashes and unhappiness, and by comparison, 11 extra delegate lines seem alright.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.