DevTools: Hide Devices drawer view in mobile targets

BUG=388348

Review URL: https://codereview.chromium.org/352373003

git-svn-id: svn://svn.chromium.org/blink/trunk@177083 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix issue with selection being lost when InsertListCommand changes the list type.

When changing the list type (from ordered to unordered or vice-versa) of a list item,
a new list containing that list item is created.
Now, if that same list item (contained within the new list) is selected in its entirety and then
its list type reversed again, it merges itself back into the original list.
However, post this merge, the selection over that list item is lost.

The selection is lost because we lose the 'start' of the selection. We thus ought to maintain
the start index of the selection in the same way we maintain the end index of the selection before
merging the two lists.(Done in InsertListCommand::doApply())

The reason why this behavior is observed only when a list item is selected in its entirety is
because we do preserve the start of the selection in case the original selection spans across
multiple paragraphs, but skip this (the if check in doApply()) if the start and the end of the
selection lie on the same line.

So now, we simply need to maintain the indices for the start and the end of the selection before
we insert or merge new lists. Afterwards, we can reset the ending selection using these start
and end indices.

The selection range for the existing test, insert-list-nested-with-orphaned.html changes with
this fix. It now sets the selection over the entire list, as expected.
The test initially sets the selection over the entire list which was later lost after
performing the insertOrderedList command.

BUG=328030

Review URL: https://codereview.chromium.org/114043002

git-svn-id: svn://svn.chromium.org/blink/trunk@177084 bbb929c8-8fbe-4397-9dbb-9b2b20218538