Open Radar

 
Summary:
WebHTMLView delegates many editing actions to the delegate by way of a COMMAND_PROLOGUE macro that translates to a call to the delegate's -webView:doCommandBySelector: method.

The problem is for some editing actions, at least including but possibly not limited to "changeAttributes:", any meaningful action in response to the action depends upon the actor having access to the sender of the message. In the case of changeAttributes:, for example, it is not necessarily the shared NSFontPanel sending the message, but a private subview (NSFontEffectsBox). The consequence is that the editing delegate has no way of consulting the sender to e.g. invoke "convertAttributes:" and determine what specific kind of editing operation has been conducted.

The problem would be addressed by supporting, for some or all of the delegated actions, a parameter to pass along the sender. For example, instead of:

-webView:doCommandBySelector:

It would instead dispatch to:

-webView:doCommandBySelector:sender:

Alternatively, if a change in the delegation API is too disruptive, it would be a quick fix to stash the sender for the duration of the dispatch, such that a delegate could ask the web view for the "current command sender" and act upon it as appropriate.

The private nature of both WebHTMLView and NSFontEffectBox leave a WebView editing delegate (such as my app, MarsEdit) unable to work around this shortcoming in any way except to (shudder) swizzle WebHTMLView to replace its implementation of changeAttributes: with one that performs the desired action. Because WebHTMLView is an internal class to WebKit, it's not possible to subclass it or to augment in any more supported or safe manner.

The practical effect of this bug on my app is that I can't react meaningfully to certain Font Panel actions such as changing the strikethrough formatting of text. I handle other font editing commands such as changeFont:, which suffers the same problem but for which consulting -[NSFontPanel sharedFontPanel] is a suitable workaround to getting access to the sender (at least given current implementations).
 
See http://stackoverflow.com/questions/4411315/how-can-i-react-meaningfully-to-a-changeattributes-delegation-pass-through-from for previous context for this bug report.

Steps to Reproduce:
1. Implement any app with a web editing delegate that specializes behavior of the changeAttributes: action.
2. From an editable web view, open the font panel.
3. Invoke the e.g. "strikethrough" popup panel and selection a strikethrough option.
4. From the web editing delegate's doCommandBySelector: method, observe that there is no way to reliably consult the sender that originated the command. Thus, no e.g. meaningful convertAttributes: calculations can be made.


Expected Results:


Actual Results:


Version:
This has been a longstanding bug but still exists in 10.11 betas.
10.11 Beta (15A244d)

Notes:


Configuration:


Attachments: