After m_start = m_start.downstream(), m_start might get into editing boundaries. This bug will cause a lot of crashes editing with Shadow DOM.
I'm now making a patch. I'll submit it soon.
(In reply to comment #0) > After m_start = m_start.downstream(), m_start might get into editing boundaries. What do you mean by getting into editing boundaries? Are you saying that it erroneously crosses editing boundaries?
(In reply to comment #2) > (In reply to comment #0) > > After m_start = m_start.downstream(), m_start might get into editing boundaries. > > What do you mean by getting into editing boundaries? Are you saying that it erroneously crosses editing boundaries? Sorry for ambiguous term... Yes, you are right.
Created attachment 144334 [details] Patch
Comment on attachment 144334 [details] Patch Attachment 144334 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12841255 New failing tests: editing/execCommand/delete-table-with-empty-contents.html editing/selection/selection-plugin-clear-crash.html editing/selection/4895428-4.html editing/pasteboard/replacement-fragment-remove-unrendered-node-crash.html
Created attachment 144344 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment on attachment 144334 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144334&action=review > Source/WebCore/dom/Position.cpp:93 > + if (position.anchorType() == Position::PositionIsAfterAnchor) { In my humble opinion, if this condition is changed to *if ~ else if* or *switch ~ case*, it seems to me "return position;" on line 100, line 110 can be removed. > Source/WebCore/dom/Position.cpp:116 > + It looks this is unneeded line.
Created attachment 144519 [details] Patch
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12840551
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/12839572
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/12849457
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/12849497
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12843524
Comment on attachment 144519 [details] Patch Attachment 144519 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12850492
Comment on attachment 144519 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144519&action=review > Source/WebCore/dom/Position.cpp:80 > + Node* node = position.deprecatedNode(); Please try not to use deprecatedNode and/or anchorNode in new code unless you're explicitly checking the position's type. See https://rniwa.com/2011-06-26/position-and-anchor-types/ > Source/WebCore/dom/Position.cpp:85 > + if (node->parentNode() && node->parentNode()->rendererIsEditable() != node->parentNode()->rendererIsEditable()) When could node->parentNode()->rendererIsEditable() ever be different from node->parentNode()->rendererIsEditable()? We definitely need a test case that executes this line. r- because of this. > Source/WebCore/dom/Position.cpp:91 > +static PositionIterator visiblePositionIterator(const Position& position) I don't understand what this function does. Please make the function name more descriptive of what it does. > Source/WebCore/dom/Position.cpp:96 > + return createLegacyEditingPosition(position.anchorNode(), caretMaxOffset(position.anchorNode())); Please don't instantiate legacy positions. I think you're not fixing the bug properly if you have to instantiate legacy position here. > Source/WebCore/dom/Position.cpp:109 > + default: In most cases, we prefer listing all values of enum in switch statements instead of using the default label.
Created attachment 145000 [details] WIP
Comment on attachment 145000 [details] WIP Attachment 145000 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12861310 New failing tests: editing/execCommand/delete-table-with-empty-contents.html editing/selection/selection-plugin-clear-crash.html editing/selection/4895428-4.html editing/shadow/selection-crossing-editing-shadow-boundaries.html
Created attachment 145076 [details] Archive of layout-test-results from ec2-cr-linux-02 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment on attachment 145000 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=145000&action=review > Source/WebCore/dom/Position.cpp:638 > +#if 0 I think it is better to write a comment to explain why below codes is disabled. For example, http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/qt/QtTapGestureRecognizer.cpp#L135 > Source/WebCore/dom/Position.cpp:765 > +#if 0 ditto.
(In reply to comment #19) > (From update of attachment 145000 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=145000&action=review > > > Source/WebCore/dom/Position.cpp:638 > > +#if 0 > > I think it is better to write a comment to explain why below codes is disabled. > > For example, > http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/qt/QtTapGestureRecognizer.cpp#L135 > > > Source/WebCore/dom/Position.cpp:765 > > +#if 0 > > ditto. It's just a work-in-progress patch to use EWS. Sorry if confusing.
unassigned me for now. This is not only Shadow-related problem. I might attack this later though.