Test case at http://persistent.info/webkit/test-cases/contenteditable-select-all-bug.html
Doing a "select all" operation (either from the keyboard or the edit menu) while the cursor is in the "content content..." paragraph does not work as expected in the first contenteditable area. Instead, the cursor is moved to the end of the area.
This appears to be triggered by the first element in the in the contenteditable="true" container being a contenteditable="false" div (the red rectangle). If that node is editable (the green rectangle version), then everything works as expected. I expect this is a bug in highestEditableRoot in htmlediting.cpp, or somewhere around there.
I can reproduce this in Safari 6.0.2 and Chrome 26.0.1386.0.
Created attachment 211772[details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 211775[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212345[details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212347[details]
Archive of layout-test-results from webkit-ews-16 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-16 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212351[details]
Archive of layout-test-results from webkit-ews-03 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-03 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212449[details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212451[details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212452[details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212465[details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212467[details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212472[details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212569[details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212575[details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212614[details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212619[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212627[details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212663[details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212664[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 212683[details]
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-13 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Created attachment 212686[details]
Archive of layout-test-results from webkit-ews-04 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.5
The test
fast/block/float/relative-painted-twice.html is faling.
But I think we need to update the expected output of this test.
--- /Volumes/Data/EWS/WebKit/WebKitBuild/Release/layout-test-results/fast/block/float/relative-painted-twice-expected.txt
+++ /Volumes/Data/EWS/WebKit/WebKitBuild/Release/layout-test-results/fast/block/float/relative-painted-twice-actual.txt
@@ -8,4 +8,3 @@
layer at (8,58) size 769x0
RenderBlock (relative positioned) {DIV} at (0,0) size 769x0
RenderBlock (floating) {DIV} at (0,0) size 100x100 [bgcolor=#0000007F]
-caret: position 0 of child 1 {DIV} of child 1 {DIV} of child 1 {DIV} of body
Comment on attachment 212679[details]
Patch
Can we do this as a reference test instead? The test is failing on the EWS bot, so something more has to be added to the patch before we can land it.
(In reply to comment #54)
> (From update of attachment 212679[details])
> Can we do this as a reference test instead? The test is failing on the EWS bot, so something more has to be added to the patch before we can land it.
Thanks for review
I have updated the patch.
Comment on attachment 212894[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=212894&action=review> Source/WebCore/ChangeLog:9
> + Test: editing/selection/select-all-with-div-noneditable.html
> +
This line should appear after the long description but before the list of files and function names.
> Source/WebCore/ChangeLog:16
> + But editableRootPosition, highestRootEditablePosition and
> + rootEditablePosition return 0 for nonediatble element due to which
> + the check for position to be under same highestRootEditable element
> + fails.
This doesn't justify the change. Why should that matter at all? It appears to be that this is a bug in VisibleSelection, not PositionIterator.
>
> > Source/WebCore/ChangeLog:9
> > + Test: editing/selection/select-all-with-div-noneditable.html
> > +
>
> This line should appear after the long description but before the list of files and function names.
Sorry I will update.
>
> > Source/WebCore/ChangeLog:16
> > + But editableRootPosition, highestRootEditablePosition and
> > + rootEditablePosition return 0 for nonediatble element due to which
> > + the check for position to be under same highestRootEditable element
> > + fails.
>
> This doesn't justify the change. Why should that matter at all? It appears to be that this is a bug in VisibleSelection, not PositionIterator.
Why you think that cause of issue is around VisibleSelection?
What I found is:
<div id= = "1" contenteditable = true>
<div id = "2" contenteditable = false>
</div>
<p>This is candidate</p>
</div>
In above scenario the selectAll range startPosition anchornode is div(id = "2") and
end position is <p>.
since div(id="2") is disable the check that div and p are under same editableContent(div id ="1") fails setting startPosition to NULL (in Cannonical position)
and if startposition is NULL we make it equal to end position. so final selection is caret selection.
and the fix is in isCandidate()
Basically I am ignoring position with empty noneditable position and blockheight to be a candidate.
Overall it looks fine to me considering the tricky editing code.
Please suggest if you have something in mind.
So its failing at calculating start VisiblePosition.
> WebKit.dll!WebCore::VisiblePosition::canonicalPosition(const WebCore::Position & passedPosition={...}) Line 532 C++
WebKit.dll!WebCore::VisiblePosition::init(const WebCore::Position & position={...}, WebCore::EAffinity affinity=DOWNSTREAM) Line 58 + 0x10 bytes C++
WebKit.dll!WebCore::VisiblePosition::VisiblePosition(const WebCore::Position & pos={...}, WebCore::EAffinity affinity=DOWNSTREAM) Line 52 C++
WebKit.dll!WebCore::VisibleSelection::setBaseAndExtentToDeepEquivalents() Line 254 + 0x17 bytes C++
WebKit.dll!WebCore::VisibleSelection::validate(WebCore::TextGranularity granularity=CharacterGranularity) Line 417 C++
WebKit.dll!WebCore::VisibleSelection::VisibleSelection(const WebCore::Position & base={...}, const WebCore::Position & extent={...}, WebCore::EAffinity affinity=DOWNSTREAM, bool isDirectional=false) Line 68 C++
WebKit.dll!WebCore::VisibleSelection::selectionFromContentsOfNode(WebCore::Node * node=0x0af44c38) Line 100 + 0x2e bytes C++
WebKit.dll!WebCore::FrameSelection::selectAll() Line 1649 + 0x12 bytes C++
It appears to me that this bug is about adjustSelectionToAvoidCrossingEditingBoundaries not using the right position or that VisiblePosition::canonicalPosition not being able to handle this situation properly. There is nothing wrong with isCandidate.
2013-09-16 05:31 PDT, Santosh Mahto
2013-09-16 06:13 PDT, Build Bot
2013-09-16 06:39 PDT, Build Bot
2013-09-23 05:53 PDT, Santosh Mahto
2013-09-23 06:57 PDT, Build Bot
2013-09-23 07:41 PDT, Build Bot
2013-09-23 08:01 PDT, Build Bot
2013-09-24 03:06 PDT, Santosh Mahto
2013-09-24 03:53 PDT, Build Bot
2013-09-24 04:11 PDT, Build Bot
2013-09-24 05:16 PDT, Build Bot
2013-09-24 06:42 PDT, Santosh Mahto
2013-09-24 07:29 PDT, Build Bot
2013-09-24 07:53 PDT, Build Bot
2013-09-24 08:47 PDT, Build Bot
2013-09-25 05:11 PDT, Santosh Mahto
2013-09-25 05:40 PDT, Santosh Mahto
2013-09-25 06:31 PDT, Santosh Mahto
2013-09-25 06:49 PDT, Build Bot
2013-09-25 07:27 PDT, Build Bot
2013-09-25 10:54 PDT, Santosh Mahto
2013-09-25 11:19 PDT, Santosh Mahto
2013-09-25 12:07 PDT, Build Bot
2013-09-25 13:28 PDT, Build Bot
2013-09-25 14:27 PDT, Build Bot
2013-09-25 20:45 PDT, Santosh Mahto
2013-09-25 21:51 PDT, Build Bot
2013-09-25 22:11 PDT, Build Bot
2013-09-26 02:15 PDT, Santosh Mahto
2013-09-26 03:01 PDT, Build Bot
2013-09-26 03:23 PDT, Build Bot
2013-09-28 04:13 PDT, Santosh Mahto