This module is required in order to alienate all extension blocks
by default. Otherwise they are interpreted as plain divs which
allow content editable.
Bug: T103455
Change-Id: I08f6b9a516ba6bee6ed18256222108116eceee1e
When loading VE by clicking Edit on a view url, this naturally
works (we temporarily append our query, and remove it when ready).
When loading VE from a permalink (e.g. Open in new tab) or any
other source linked from HTML pages, then we're not in control
over adding the query (it's already there); we're only in control
over restoring the view url afterwards.
Bug: T102363
Change-Id: I4912ff1c6b28ac987517760ffed481a4cd3bd1ca
Once MW images are registered, we should remove core image support so
we don't accidentally match to them (e.g. an MW inline image with an
unsupported extra RDFa type).
Change-Id: I1c8567346c371fe338f95b232c9ac53e009c5a46
All this is no longer needed since 121216184718e7ebe22d6ecc8f5af5fe4e202465 in
OOjs UI and started causing issues after bb9c9c4f6a2fca6aed0e671e904e469d57da5f34.
Bug: T98795
Change-Id: I6493d6b52b313aac521aee2b0cff1571ea63bbe5
* Add a 3rd stage will triggers on API load
* Allow stages to complete in different order (as happens
on second load)
* Use CSS transitions
* Start slow and speed up using ease-in and progressively
shorter transitions
Bug: T95137
Change-Id: Ib9090e6c80b7a186bf353c40921d40456d90211a
The toolbar.destroy() call that was added in 5c38995bd9 was
needed to destroy the dummy toolbar when tearing down VE
before a surface had been intialized. But when tearing down
VE after the surface had been initialized (e.g. exiting using
the Read tab), we would do:
* setTimeout in tearDownToolbar()
** Set toolbar height to 0 and wait for transitionend
*** toolbar.destroy() once transition complete
* toolbar.destroy() in cancel()
This meant that we'd listen for a transitionend event
on an unattached element (because once the setTimeout runs,
the toolbar has already been destroyed by the second call),
which of course never fires, so we'd never resolve the
tearDownToolbar deferred and never finish tearing down VE.
Bug: T98388
Change-Id: I504f0cb0bf13643773fc98cb18b7b380cccb2f88
Prevents read-mode elements placed inside the target from
getting scaled down (e.g. firstHeading).
Change-Id: I55ed38e2855c4eb317ec71cebb1842b9b70790b6
This is no longer needed, as VisualEditor now loads the content
from the /api/rest_v1/ entry point at the main project domain.
This reverts commit c741db5378.
Bug: T97500
Change-Id: I9b0dba58484884cdf3c7917c633b9815de4c9f92
The old code in ve.init.mw.Target.static.fixBase was mostly
moved to ve.fixBase(), and the new ve.init.mw.Target.static.fixBase
contains MW-specific logic on top of that. This allows us to get
rid of the base fixing logic in onLoad().
Depends on I607fa579733 in VE core.
Change-Id: I42dfd4b90e86eb67d0111fffafc18e1152249610
If a load failed due to a revid mismatch, and a new attempt then
succeeded, we would keep remembering that it initially failed.
Then when we loaded the editor a second time, encountering
a revid mismatch would cause us to give up immediately.
To fix this, forget about any previous failures once
a load succeeds.
Bug: T97069
Change-Id: Ie10a7532759095cbb5fb8d23af602aa7b9611a06
Depends on Idd5e163090c9cf1c103d8b40e8ba19d332671cde and
Ifba178d8099b797a0ca33ca990540c8cb9cd3637 in VE core.
Bug: T65227
Bug: T70425
Bug: T95819
Change-Id: I6f08e3c1c3e4134520dac1e2d32d828cdefea23f
These are likely to have been generated by a parent language setting,
rather than an a specific inline annotation.
This won't affect ve-to-ve copy paste.
Bug: T95708
Change-Id: Ic8fe417ab6ffa74e85ab170f413b13b83589293d
