Repository: oppia/oppia

Issue:
Second item is selected in CKEditor for Drag and drop interaction
On adding the drag and drop interaction, you'll see two items. The second is highlighted whereas ideally the first should be highlighted one. 

Here is screenshot for the same:

![screenshot from 2018-08-11 20-23-46](https://user-images.githubusercontent.com/22434689/43993188-52e76022-9da7-11e8-9b6b-64bc25f690ef.png)


cc @vibhor98 


Discussion:
This is the default behaviour of CKEditor. Its common for all the interactions as verified by @bansalnitish. I haven't done any changes with the CKEditor. Probably, Nitish can say more about the issue. 
This is not the default behavior of CKEditor. The issue is that there are two CKEditor input fields at the outset (not common) and presumably both are being autofocused at the same time. Maybe find a way to manually set focus to the first one?

I.e. it's not a CKEditor issue, I think. It's how we use the CKEditor on the page.
Yup @seanlip is right. It's not the RTE issue and we don't have any interaction with two items or so. 
While looking at the `label-for-focus-target` for schema based editors, I found that it was disabled as CKEditor has its own Focus Manager to keep track of the elements. After looking at its documentation, I found that `CKEDITOR.editor.focus` method is used to move the selection focus to the editing area space in the editor  ([link](
https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_editor.html#method-focus) to the doc). 

@bansalnitish, Can you confirm whether we're using such method to focus the editable area in the editor? If yes, then each time the editor loads, its editable area will be highlighted (focused) and in the case of this issue, the latest editor (i.e. second one) is highlighted (as reported). Otherwise, how are we actually managing this behaviour using `FocusManager`?
Hi @vibhor98,

We are using the default behaviour of CKEditor for managing the foucs. So, if the default behaviour is to highlight the latest instance of editor, you will need to change that specifically for Drag and drop interaction. 

In other cases, this behaviour is the expected one. Like in case of tabs, we have two CKEditor instances but since both have some text, the right behaviour is to highlight the latest one which has text. In case of multiple choice and item selection, we only have single instance and new instances are added using Add new item option. When a new instance is added, that is the latest one and it should be highlighted.

This should be different for drag and drop since both instances are empty and so we need to highlight the former instead of the latest here.

Another fix would be to have some default value in both instances, then it would be fine to highlight the latest one.
I don't think there's a reasonable nonempty default value to use here. It's going to be annoying for the creator to have to delete that value each time.

I think the potential solutions include:
- finding a way for the focus to be on the first element (for the drag-and-drop interaction)
- having just one field as the default, but preventing saving unless there's >= 2 fields.
Yeah the second one can be easier I guess. 
> having just one field as the default, but preventing saving unless there's >= 2 fields.


Resolving patch:
diff --git a/extensions/interactions/DragAndDropSortInput/DragAndDropSortInput.py b/extensions/interactions/DragAndDropSortInput/DragAndDropSortInput.py
--- a/extensions/interactions/DragAndDropSortInput/DragAndDropSortInput.py
+++ b/extensions/interactions/DragAndDropSortInput/DragAndDropSortInput.py
@@ -38,7 +38,15 @@ class DragAndDropSortInput(base.BaseInteraction):
             'type': 'list',
             'validators': [{
                 'id': 'has_length_at_least',
-                'min_value': 2
+                # NOTE: There is slightly stricter validation of the number of
+                # minimum choices in frontend. It should be at least 2 from the
+                # frontend perspective but we can't impose it here as min_value
+                # in the customization schema determines the number of RTEs that
+                # appear in the customization modal initially that needs to be
+                # 1. Here min_value: 2 and default_value: [''] aren't allowed as
+                # default_value needs to be at least of same length as min_value
+                # else schema tests for customization args will fail.
+                'min_value': 1
             }],
             'items': {
                 'type': 'html',
@@ -52,7 +60,7 @@ class DragAndDropSortInput(base.BaseInteraction):
                 'add_element_text': 'Add a new item',
             }
         },
-        'default_value': ['', ''],
+        'default_value': [''],
     }]
 
     _answer_visualization_specs = []


Test patch: