Bug 34146 – _selectedOrMainFrame should consider caret selection in determining a target frame

• Component: WebKit API
• Status: UNCONFIRMED

[Daniel Jalkut]

Currently _selectedOrMainFrame relies only on the official "selectedFrame" method on WebView, which considers a frame selected only if it has a non-zero-length selection.

Many of the methods that invoke _selectedOrMainFrame to determine the "selection" would behave more meaningfully in a non-firstResponder state, if frames that had caret selection were considered in the search for the most appropriate target frame.

Consider for example a WYSIWYG editor window where a non-editable mainFrame contains a contentEditable frame. While the view is not first responder, it may still retain a caret insertion selection that is a legitimate target for many methods such as replaceSelectionWithMarkupString:, etc.

I do not believe that including caret selection frames in this private method's search criteria would cause any negative impact for any existing code. Because most of these methods are simply (infuratingly ;) ) failing now to do what the developer wishes they would do, I think that expanding the target criteria for frames would only result in an increase in "desirable behavior" when determining the implicit selection.

I will submit a patch for this if the notion of extending _selectedOrMainFrame's behavior isn't met with immediate dismissal ;)

Daniel

[Daniel Jalkut]

Another issue that seems doubtless related, is any changes to a WebView's preferences object do not trigger relayout of the IFRAME contents unless there is a literal selection. I.e. if you are editing inside an IFRAME, inside a webview, and the preference for, say, the defaultStandardFont changes, then the content of the IFRAME:

- WILL be updated if there is any active selection range.

- WILL NOT be updated if there is only a caret selection.

The inconsistencies stemming from the decision to treat a caret selection as "not a selection" seem to be vast and varied.

[Daniel Jalkut]

Please disregard this comment. I believe I was misled by another circumstance of my testing, and since it seemed so similar to the issue reported here originally, I thought I would tack it on.

I no longer think that style changes being applied to IFRAME have any relationship to whether there is a selection or not.

Daniel

(In reply to comment #1)
> Another issue that seems doubtless related, is any changes to a WebView's
> preferences object do not trigger relayout of the IFRAME contents unless there
> is a literal selection. I.e. if you are editing inside an IFRAME, inside a
> webview, and the preference for, say, the defaultStandardFont changes, then the
> content of the IFRAME:
> 
> - WILL be updated if there is any active selection range.
> 
> - WILL NOT be updated if there is only a caret selection.
> 
> The inconsistencies stemming from the decision to treat a caret selection as
> "not a selection" seem to be vast and varied.