bzr revid: psa@tinyerp.com-20131021074817-3yren0baw8fqijie

bzr revid: psa@tinyerp.com-20131021054510-mm8trh1okva40mrt

bzr revid: fp@openerp.com-20131020093502-mn4c6s91up3bmqbu

bzr revid: fp@openerp.com-20131020092215-ljejg7i0rh9e0km9

bzr revid: fp@openerp.com-20131020091918-yfr7w8a706pdnbxk

bzr revid: fp@openerp.com-20131019211709-5zxz9601fw7qtu1k

bzr revid: fp@openerp.com-20131019210050-1fcn80fmqc2w66sd

bzr revid: fp@openerp.com-20131019205931-t00sxvx71a3wcx3h

bzr revid: ddm@openerp.com-20131018163341-j5bf8sqj4wz8yp14

bzr revid: rgaopenerp-20131018145313-4li3mwyte19n0cf9

bzr revid: psa@tinyerp.com-20131018140436-go7nyqsrw2u6ncu3

bzr revid: ddm@openerp.com-20131018135926-vdmelqsp1ama13st

bzr revid: psa@tinyerp.com-20131018134347-gbvtw3diw1lrli6k

bzr revid: psa@tinyerp.com-20131018134149-1s7goa7nsm1tz2tg

bzr revid: psa@tinyerp.com-20131018133010-3zuv4ibxqpzx0jvj

bzr revid: psa@tinyerp.com-20131018130256-gr9ikd0iiszvgsmg

bzr revid: fme@openerp.com-20131018130034-vo6rgndvzv1ni6nu

bzr revid: psa@tinyerp.com-20131018123244-ueuj25lto0ugs6mj

bzr revid: chm@openerp.com-20131018114116-ywe7pp49f2cb0dor

CKEditor's tab plugin can't deal with a non-editable editor root
(editor.editable().hasFocus returns false and disables it), so
reimplement the behavior.

For some reason, ckeditor's selection API also does not seem to work
correctly in table cells in Firefox, so use the browser's native API
instead.

Tab goes to the next cell, shift-tab goes to the previous cell,
shift-tab from the first table cell is ignored and tab from the last
table cell creates a new row and sets focus in the new row's first
cell. These behaviors seem to more or less match Word and OpenOffice
Writer's.

bzr revid: xmo@openerp.com-20131018103540-12p8j18ypte8dr9u

bzr revid: rgaopenerp-20131018094116-iogn36mj1hbsvhn0

bzr revid: rgaopenerp-20131018093135-4ux25wdnd73wlah2

bzr revid: fp@tinyerp.com-20131017141959-fpkds0a7e1m1sfrw

bzr revid: xmo@openerp.com-20131017133133-uebgw7m3fo9as38s

bzr revid: ddm@openerp.com-20131018092820-lqj9yz518262nknr

bzr revid: chm@openerp.com-20131017131604-x2xo963p9pq81hvf

bzr revid: psa@tinyerp.com-20131017131321-uyyyp9nii5ab8ejx

bzr revid: psa@tinyerp.com-20131017130421-fnir86hberl2t6qy

bzr revid: ddm@openerp.com-20131017115849-e696n3tj87zx3a9i

bzr revid: psa@tinyerp.com-20131017095125-uf4dm2jfy7a0sla4

bzr revid: psa@tinyerp.com-20131017071144-k58tomhtjit4n126

bzr revid: ddm@openerp.com-20131016160232-e5rxi1hoofm5anrw

bzr revid: fme@openerp.com-20131016151257-0r42s8t3xevabfm3

bzr revid: ddm@openerp.com-20131016143939-v0v1tcopq4zoqgxf

its isReadOnly() calls generates quite a bunch of timeline events

bzr revid: xmo@openerp.com-20131016133432-4aq30rd8szbs2bef

bzr revid: ddm@openerp.com-20131017104053-shrwu5ariisq7ub5

bzr revid: ddm@openerp.com-20131017083534-outfljvfqjomfxgv

Mutation events are synchronous and one is triggered per observed
alteration (they're not batched). When doing lots of modifications to
the DOM tree, they will add a lot of overhead as (in this case) the
event handler will run for *each* added node and it will run during
(and slow down) node insertion rather than afterwards.

bzr revid: xmo@openerp.com-20131016123708-lx389x0g6xs6zu10

bzr revid: chm@openerp.com-20131016122905-w93f4vtamiqy79lo

bzr revid: chm@openerp.com-20131016104545-e415ixicw2crci2w