[FIX] web: inputs of an editable list inside a modal are broken

This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).

Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:

                                                       .modal
                                                 /             \
                                         ... (new S.T.)    ... (new S.T.)
                                           /                      \
                                  ... (new S.T.)              ... (new S.T.)
                                 /
                       .o_list_editable (new S.T.)
                      /                            \
           .o_form_view (new S.T.)         .table-responsive (new S.T.)
      /            |           \                           \
input            input           input                      table (new S.T.)

This explain why the input are not visible: actually, they are displayed
behind the table. In this case the  document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004 [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.

The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.

The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.

With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.

This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.

opw 683169

cherry-pick of odoo/enterprise@35f285e50a

[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c7
and never forward-ported to saas-10.

addons/web/static/src/js/views/list_view_editable.js

@@ -432,6 +432,11 @@ ListView.include(/** @lends instance.web.ListView# */{
             field.$el.addClass('o_row_handle');
         }
 
+        // Workaround a bug in safari mobile where the inputs are not displayed correctly.
+        if (window.getComputedStyle(field.el.parentElement).webkitOverflowScrolling) {
+            field.el.style.zIndex = 1;
+        }
+
         function position_element($el, pos) {
             $el.addClass('o_temp_visible').css({top: 0, left: 0}).position({
                 my: pos,

addons/web/static/src/less/list_view.less

@@ -204,6 +204,15 @@
     }
 }
 
+// Workaround a bug in safari mobile where the inputs are not displayed correctly.
+.modal {
+    .o_list_editable {
+        .o_form_view.o_list_editable_form {
+            -webkit-overflow-scrolling: auto;
+        }
+    }
+}
+
 // Buttons in ControlPanel
 .o_list_buttons {
     .o_list_button_save, .o_list_button_discard {