Stripped out X-Parsoid Performance Headers, previously used to gather and
forward Parsoid's performance information, from ApiVisualEditor.php,
ve.init.mw.Target.js and ve.init.mw.TargetLoader.js. Change I936ada7b1 strips
out the corresponding X-Parsoid Performance Headers from Parsoid. Parsoid's
current performance instrumentation is achieved using Graphite and txstatsd.
Change-Id: I57d6f866a7d8287a5115e6236b0fb25bc4d0eabd
It's much less likely we'll get another conflict if we retry
with ?oldid=12345 than if we retry omitting the oldid again.
Change-Id: I10e40f714fd44d7f0ac16c9d0dc6239a95c0ec51
With RESTbase we'll be able to retry the older one, but right now we have to do
both with the same request.
This commit retries loading once, then starts emitting errors.
Bug: T92993
Change-Id: Ifbf44b777279dafbe31ab438838d70acd44de726
When we moved to mw.Api, edit conflict errors stopped going via onSave and
started going to onSaveError instead. So the case to check for them in onSave
would not have worked - instead, they would go through onSaveError and get
picked up by our unknown error code, which just picks out error.info and shows
it, instead of showing our edit conflict screen.
Also return in a couple of other error cases where we probably should've been
(but not necessarily must've been... that didn't necessarily show to the user
if another error emit already caused saveDeferred to be rejected)
Change-Id: Iae7a66a8aa96ee777e9fa780005feeb429129d5f
Relies on I69cf0a88
Using our own new message because TitleBlacklist's own one includes text that
we can't parse on the client and relies on a parameter we don't get from the
API.
This relies on WikimediaMessages' version of the Edit schema being updated at
the same time.
Change-Id: I4c75369b8b97973b72899bfaecbd5a996a440c68
Move requestPageData from mw.Target to TargetLoader, call it
in init init, and pass the promise it returns into load()
via activate().
Bug: T90372
Change-Id: I828b8474e5a76b3d0d7d08735b4d865c29d2f820
This introduces TargetLoader, which manages plugins and RL modules
in a slightly more generic fashion so that Targets themselves don't
have to. This allows us to load all RL modules in one load.php
request, rather than first loading ViewPageTarget which then
loads the other modules.
TargetLoader loads in the bottom queue, so it will be loaded
as part of the main load.php request, but in VPT.init.js we
still have to wait for it with using() because it might not
have arrived yet. This also degrades gracefully on cached pages
where TargetLoader isn't in the bottom queue: it'll be loaded
as a separate request instead, which is suboptimal but no
worse that what we were doing before.
Right now TargetLoader is small enough that it could also be in
the top queue, but in the future we want to add things like
the action=visualeditor API request to it, and mw.Api is
relatively big.
Note: this also makes a breaking change to the plugin API:
plugin callbacks no longer receive the target instance
as a parameter, as they're now executed before the target
has been constructed rather than after. In the long term,
if we want to give plugins access to the target instance,
we could give them the target promise somehow. For now,
I've killed this feature because nothing used it and
the change from a direct object reference to a promise
would have been a breaking change anyway.
Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init.
Bug: T53569
Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
It seems to have been intended to allow overriding of which icons
are used, but this isn't used anywhere.
Change-Id: I312f6c8e69d5a4d9c11f4af5f9487d0890a1f4e1
The #tryWithPreparedCacheKey method was assuming that the request
could only fail because of invalid cache key. It can also fail because
of a bad token, and probably for a number of other reasons.
So only retry only once, and then fail. If it's a 'badtoken' error
during save, the caller will handle it and retry with a working token.
If it's something else, who knows, but we don't go into infinite loop
at least.
Failing in a way that will be handled is weird because 8e48f945 changed
the signatures of the promises, but not the functions that use them.
This must be fixed later.
Bug: T91158
Change-Id: I103cf888d339b44e3fd4fe2376edf5e37ce4157f
New changes:
a65ad7c Move special character inserter to toolbar dialog manager
… and add it to the toolbar as a terminal option.
Change-Id: I35834d866a13c5dea7f5a520c63b8a99451fcf6d
Add checks so it doesn't generate and register the same
tool twice. This makes it safe to run it multiple times.
Change-Id: I882b51bd0422222f2e80555910c69b059136a503
New changes:
04a5947 Localisation updates from https://translatewiki.net.
dd4691b Update OOjs to v1.1.5
2e1a0bb Context refactor
Local changes:
Add context item support for references, citations, templates and links
Change-Id: I5d488ecbf9768dc63de6e545505dbfd5eb84cc61
This will allow us to more easily split the API request
into two requests (one for the HTML, one for metadata)
by returning a $.when() promise, and to initiate these
requests earlier (by storing a promise and returning it
in this method).
Change-Id: I4a5d1b8c47a3dc2edfe89925e63dcf90d7038e45
Still to load at this point are
* Additional modules (first load only)
* Parsoid HTML
To account for this we disable the toolFactory event listeners
to prevent flickering, and create a hidden blank dummy surface to
attach the toolbar to.
Bug: T76523
Change-Id: Iab24858f23f4db944dcaa6683a82b950ea9ee1b1
New changes:
0ceafd5 Fix V8 deopt for ve.ce.BranchNode#onSplice
01d2d4b [BREAKING CHANGE] Store originalDomElements instead of htmlAttributes
96005a7 Localisation updates from https://translatewiki.net.
42e672e ve.ui.Toolbar: Don't call #updateToolState from #initialize
373562d Localisation updates from https://translatewiki.net.
Local changes:
Update for htmlAttributes going away
Change-Id: I576a1e5d5883b03d1fff6666926f80a5682a280f
Otherwise it gets built lazily when building the view tree,
and that makes it difficult to instrument it separately.
Change-Id: Ie8c2027e87a87e59323165f0edbba49c4a66d1b3
Tracked stages are:
* activate: wraps the entire activation
* domLoad: API request for Parsoid HTML
* parseResponse: parse HTML, interpret things like link cache data
* convertModelFromDom: create linear model from Parsoid DOM
* createSurface: build DM and CE trees, create DM, CE and UI surfaces
* initializeSurface: initialize UI and CE surfaces, and CE nodes
* setupToolbar: toolbar setup and attachment
* initializeToolbar: toolbar initialization (deferred so not wrapped by activate)
Bug: T89536
Change-Id: Ife5664e872bad68dcf3c123f274f9c8a38a06031
It's slow, especially on large pages, and it's triggered
very infrequently these days, and only for known bugs.
In the future we should replace this with a debugging
interface that displays the DOM diff between the original
DOM and the round-tripped DOM, as opposed to the boolean
interface we have now.
By extension, this also means the visualeditor-needcheck
tag won't be applied to new edits any more, although
its registration and messages are kept around because
edits with this tag still exist in page histories.
Bug: T87161
Change-Id: I909153492a5786b4b69fccd42ce3c1d4bdb3a059
Follows-up 0547d8c8.
It's still very difficult to test whether this code works, but
doing $( newDoc ).remove( 'selector1' ).remove( 'selector2' )...
demonstrably doesn't work, because 1) the selector passed to remove()
filters the collection, it doesn't descend into it, and 2) remove()
returns the collection of removed items, so chaining it doesn't work.
Instead, use $( newDoc ).find( 'selector1, selector2, ...' ).remove();
Also normalise selectors.
Change-Id: I97f3b28c4d5120f08e5d7fbf4598ddc0c01d4ecf
* Ensure that the toolbar remains inside the target so that
target triggers still work
* To keep the page title beneath the toolbar, move it inside
the target on setup, and restore it on teardown
* Have teardownToolBar/DebugBar return promises so we know
when teardown is completely finished.
Change-Id: If2a9ce9a653aed51d21c8e8dd7795f2533d54f70
We used to send data like { title: { missing: true|false } }
With this change, we send data like { missing: [titles], existing: true|[titles] }
where 'existing' is set to true (assume all non-missing titles exist)
for current revisions and to an array of existing titles for
old revisions.
This is because we always output this data for links in the current
revision, even when loading an old revision: in that case we rely
on the client to request the omitted information, so there we can't
assume that all pages we don't have information about exist.
Bug: T88259
Change-Id: I7b58b3f669cc78fd81b60859cf76928a9087066f
If added afterwards, this causes child elements styles with
'em'-values to get redrawn (or even animated).
Bug: T88387
Change-Id: Ic1aba14b7cfe0ff6e7191f0b6052ed9cc4585fcd
* Add a class to the indentation toolbar button, similarly to what was done in
Ib0cb67151d893a5d2efccf798d6b25d197ed34d2
* Fix the definition of the indentation pull-down element acordingly.
* Restore the Indentation menu screenshot scenario, which was disabled in
I3e892baa9cb2c8c1303fab232a2b1c64ebdd8f26
Change-Id: If2d92aab6d04aa487d6f753fa7cac94f8d8215c8
I think somebody somewhere pointed to this as the reason why VE
wouldn't load when user's common.js has syntax errors, but I actually
can't reproduce that. Not sure if this is needed, but looks like a
good idea anyway.
(Once more, with feeling. Reverted broken attempt: aa531488.)
Change-Id: I252c5c20f75b3bbea51200560408dc4cfc7174f6
I think somebody somewhere pointed to this as the reason why VE
wouldn't load when user's common.js has syntax errors, but I actually
can't reproduce that. Not sure if this is needed, but looks like a
good idea anyway.
Change-Id: I3abecacf083c1c9dfb2ea30207a9911eeea54b50
This cleans up the selectors for the elements on the toolbar
so that they can be tested.
Class names in the form of ve-test-* are added to elements
that have words for labels: 'Paragraph', 'Cite', 'Insert'.
There is no other way to look up these elements in the DOM
except using the UI text, but it is different in different languages,
so this is unusable for the language_screenshots job,
which is multilingual by its nature.
Bug: T76143
Change-Id: Ib0cb67151d893a5d2efccf798d6b25d197ed34d2
Follows-up b0e8900, 447e8de, d3f26e65.
Contrary to binding a reference, this-overiddes for inline
functions gets messy and fragile. There's also a minor
performance overhead that can be avoided. No separation of
concerns, eiter, as the object is held by the closure.
Also:
* Remove left-over instances of @method.
* Remove redundant '0' argument to setTimeout.
* Use null instead of $ for apply() on static methods like $.when.
* Use .empty().append() instead of .html(). Does the same but
without additional overhead and without confusion association
with "html" which isn't used (it doesn't serialise and re-parse
or clone, it just appends when given one or more nodes).
Change-Id: I797a3667c67d52568150be9be5d043d149f22077
New changes:
9929b6d [BREAKING CHANGE] Make ve.init.target an OO.ui.Element
Local changes:
* Fix target constructors now they generate this.$element
Change-Id: Ia6bf604c67305834a3f73863a10336cfbb83fa77
