In some cases (tables?) jquery-ui sortable apparently breaks down if
any parent of the element being positioned (and the generated helper
element) is in position: relative.
Remove all of the position:relative in the way, they seem to not be
used anymore (including the one in jquery-ui, testing in IE9 doesn't
seem to expose any bug and jquery-ui references one, might have been
an issue in IE<=8 which was fixed since).
Maybe an assertion should be added to the code, which would call
#getComputedStyle() on all the #parents() of the element being made
sortable and error out if one of them has
#getPropertyValue('position') == 'relative'?
bzr revid: xmo@openerp.com-20121022131624-n8a43vgl8k4gsqk9
The making of the column invisible would happen after the header was
rendered (?), and the header would not be re-rendered afterwards. So
there would be a missing chunk of table. Make the cells invisible
instead. It's all going to be changed looks-wise anyway so meh.
bzr revid: xmo@openerp.com-20121022103935-78bm40gfotpt1ds6
Old error had added the list and the search at the same place of the
popup, leading to strange interactions as the search view is floated
to the right: in Firefox the search view would be hidden behind the
list (completely), in Chrome the search view would be visible but
"overlaid" with a transparent section of the list, and (tentative)
clicks on the search view would have no effect as they'd actually be
done on and in the list view.
bzr revid: xmo@openerp.com-20121019110804-3kg91rro91isp771
The listview does not support concurrent reload requests, either wait
for the previous reload to finish before sending the new one, or just
send a single reload.
For m2m, can wait and do a single reload so do that.
bzr revid: xmo@openerp.com-20121018134123-ox2ccq0wm3r5jwas
The facet removal from its last value being removed
(`this.remove(facet)` in the 'change' handler of the SearchQuery)
broadcasted its `remove` event, triggering the `do_search` (and
repaint) hook of the SearchView a second time right after the
`change`-triggered search.
Not only is this unnecessary and duplicated work (the `remove` is a
sync operation, so searchview-attached events haven't yet executed by
the time `remove` is called), the listview really doesn't like getting
a ``search`` signal while it's already executing a search.
So fix that.
bzr revid: xmo@openerp.com-20121018124005-6vfi7tqasz32ai8v
* visibility: hidden on the cell itself hides the whole cell including
background and borders, looks terrible
* color: transparent is supported by all supported browsers (even IE
>= 9), and it avoids breaking the cell sizes (which the usual hack —
text-indent -9999px does)
* can probably just apply visibility:hidden to eveything below the
cell itself
bzr revid: xmo@openerp.com-20121018063703-scz1yl87b7nhgx94
Only fetch the table cells of the row being edited *after* having
saved a pending edition.
Otherwise, when re-editing the same record (e.g. click between buttons
or on a readonly field), the cells are saved, the record is refreshed
destroying the cells, and when trying to get the cell positions to
position form fields correctly... the cells which don't exist anymore
return 0, 0 as their position and nothing works correctly.
bzr revid: xmo@openerp.com-20121017134351-lpmz27f1iemmsfoq
Launchpad Translations on behalf of openerp