The patch in https://bugs.webkit.org/show_bug.cgi?id=134303 generated a crash on fast/dom/HTMLObjectElement/beforeload-set-text-crash.xhtml (see https://bugs.webkit.org/show_bug.cgi?id=135055). This was caused by the renaming of selectionStart/End(Pos) members within RenderView, to prevent them from getting mixed with the ones in SelectionSubtreeRoot (which RenderView inherits from). The fix was, when in the no-named-flow-threads scenario, set both groups of parameters (the ones in RenderView and the ones in SelectionSubtreeRoot) to the correct values. A test should be created to check if a similar problem would occur when named flow threads are involved.
- the renaming of the RenderView selection parameters was not the actual cause of this
- the real problem was that now the SelectionSubtreeRoot::adjustForVisibleSelection was also being called for the no-named-flow-threads scenario, which causes the RenderView::setSelection method to be called from within itself (while performing RenderView::updateSelectionForSubtrees, the SelectionSubtreeRoot::adjustForVisibleSelection method causes RenderView::setSelection to be called again).
This caused existing test fast/dom/HTMLObjectElement/beforeload-set-text-crash.xhtml to crash. For the moment, I changed the code so that SelectionSubtreeRoot::adjustForVisibleSelection is not called for the -no-named-flow-threads scenario, but I believe its possible a similar problem would occur if the beforeload-set-text-crash.xhtml was modified to use flow threads.