clipboard plugin was getting lost due to method used to get a readonly
toplevel editor with editable sub-sections in it.
The clipboard plugin creates a hidden pasteboard element to safely get
a the clipboard data before inserting it at paste point, this
clipboard may have to be made @contenteditable if it's created in a
readonly area. Which was the case here: the pasteboard was inserted at
the root of the editor, which is not editable.
But because of @data-cke-editable being explicitly set, ckeditor would
believe it had inserted the pasteboard in an editable section and thus
would *not* set its @contenteditable leading to a useless readonly
pasteboard.
The purpose of @data-cke-editable was to make the editor itself
"editable" for cke (in order for the toolbar to not be disabled) while
it would not actually be editable (@contenteditable) for users.
This is better reimplemented by calling API methods to make the editor
editable but its root element not editable, one of the improvements
being that commands (and thus toolbar buttons) now switch state
correctly based on context.
bzr revid: xmo@openerp.com-20130924110601-gfvc395rsedpnoh3
With page urls not necessarily being full xmlids, match to result of
list_pages needs to take that in account to correctly infer a url is a
site page's.
bzr revid: xmo@openerp.com-20130923110618-ckicw4a5bpvatzie
if a link is outside a view section or is the root of the view
section, its href can not be edited (either because it's completely
non-editable or because it probably had a dynamically generated href
via t-att*)
bzr revid: xmo@openerp.com-20130919152039-5hpe8qdrvhhen5aw
CKEditor does not work directly on body, and it's a bad idea anyway
(editing the edition toolbar won't end well).
A big wrapper around all of the page's content can be used as RTE hook
to give access to the body as well as the header and footers.
bzr revid: xmo@openerp.com-20130918145028-6ppi9sro2un0quh5
CKEDITOR plugins are not loaded in dependency order (see previous
commits), and in the end the vast majority of the (used subpart of)
link and image plugins were reimplemented to handle new dialogs.
Bite the bullet, disable link and image and implement/import missing
parts (link removal, doubleclick hooks & toolbar button definition).
bzr revid: xmo@openerp.com-20130916090353-933av2nsrygxz64y
avoids automatic locale picking selecting something different than the
one locale file currently provided and blowing up, preventing edition
from working
bzr revid: xmo@openerp.com-20130913135532-szra08zdge1ktmc7
avoids automatic locale picking selecting something different than the one locale file currently provided and blowing up, preventing edition from working
bzr revid: xmo@openerp.com-20130912154957-yod17u9xvw3r966i
``inline`` is now automatically inferred on a per-widget basis if not
specified.
``inline`` true|false tells the widget whether it should work on
inlines (e.g. span) or blocks (e.g. p). Specifying the wrong one blows
up because the wrapper is incorrect (inline==false on an inline
element will wrap it in a div and add linefeeds, inline==true on a
block element will wrap it in a span which will automatically split up
in multiple elements leading to downcast blowing up because the wrong
wrapper will be selected).
Since last time, inline inference was added: if *unspecified* widget
will check what type of object it's called on (using
``CKEDITOR.dtd.$inline``) and generate the correct wrapper for that
type.
=> fix misbehavior by removing explicit inline spec.
Also remove unused init and data methods.
bzr revid: xmo@openerp.com-20130909152312-1m5kwvgw04gcrfkv
* Replace select by input with dropdown
* Add random crap to /pagenew so it does not blow up when a butterfly
flaps its wings, also so it's possible to call it through xhr and
get something out of it
* Fix duplicated save() call in link dialog widget thing
bzr revid: xmo@openerp.com-20130903143237-6pwsbqzc02bv3mri
Apparently same issue as noted in
xmo@openerp.com-20130902105411-ni3klun0k8v1tmjg, RTE and bootstrap
modal fight for focus (oddly not in Firefox), leading to the callstack
blowing up (after a fraction of a second of browser freezing).
Use same remedy, defer focus-manipulating operation to after the
dialog has been removed and destroyed in order to avoid focus fight.
bzr revid: xmo@openerp.com-20130902105637-1y9aogm1yx9z81jt
Dialog doesn't work right as it's a bootstrap 3-ish dialog, not 2, so
none of the classes works correctly.
Also moved editor templates outside of main website template file.
bzr revid: xmo@openerp.com-20130829153441-w51n3hxxikyti0xj