The when_not_visible line fails, but it doesn't seem to be needed
in the first place. The when_present line appears to be enough.
Change-Id: I572dabb5d53553d454f6e40c5602fbe3252c3657
The functionality chnaged significantly, so the steps must be changed.
Removing the tag until it's done.
Change-Id: Iacdf78d3b6f00e39cb2bf313b79489035f1c0b62
The element is <div>, and using English text doesn't work
in other languages.
Follow up to
Icd79ec9b489557c3259ff7f2c11b2a899c767d0f
Change-Id: I3859c668921a5f3f6abafb2053fc471dbc8d80c7
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
We're currently rewriting "mwtiming.performance.system.domLoad" to
"timing.ve.undefined.performance.system.domLoad". The "undefined" comes from
the missing targetName property on the event. I'm not sure why it is missing,
but having it default to 'mwTarget' will Do the Right Thing™.
Task: T93156
Change-Id: If70ff601b6c54ec8f95171cbc43c82c87a177508
We moved toward serialization, but in the case where we don't have a
rendering yet and it's happening async, we need to use the same DOM
container that will be rendered into.
Bug: T91336
Change-Id: I53920591fde02175d4162b1fe5899b97b10a5b0f
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
New changes:
44ca3b6 Use store indices in annotate operations
3ebbcce Make range optional in getUsedStoreValuesFromRange
9d03a5e Set originalDomElements whenever a data element is created
4cfffde Simplify annotation hashes
4eeb8bb Add handlers for font annotations
4a6d6f0 Localisation updates from https://translatewiki.net.
05de45e ve.ui.ToolbarDialogTool: Fix documentation
6797d6d Use type from toDataElements when creating annotations
b3a3839 Store reference to DM document in transactions
c073a24 Load special characters in Platform instead of SpecialCharacterDialog
Local changes:
* Add new files to VisualEditor.php
* Re-sort i18n strings in VisualEditor.php
* Re-run extenson.json creation
* Update documentation HTML file
* Update tests for adjacent annotations fix
Change-Id: I7a5e79e68ab8a7aae0e9af42d011943019f7f85f
Set 've-activated' as soon as edit is clicked, with a 've-loading' state.
This necessitates moving the relevant styles to mw.ViewPageTarget.init.css.
Change-Id: Ic9757cdbf63a2f72eda0dd03ff5588d79028ba0e
* Access to Cite options changed
* Various target locators also changed
Paired with Rummana for these changes.
Change-Id: Ib7c3fbd1842879745d3d3128c66d90cc2b4f98cb
If a references list node is selected, open the dialog to edit it.
Otherwise just insert the references list for the default group, since
this is what the user wants to do in 99% of cases.
* Replaced the simple 'referencesList' command (which opened the dialog)
with a custom implementation in ve.ui.MWReferencesListCommand, which
inserts the references list or opens the dialog like before.
* Removed the ability to insert a references list from
ve.ui.MWReferencesListDialog, since it should now never open without
a references list selected. If it does, throw an error.
I considered the behavior of always showing the dialog if there is at
least one references list already in the document, but I think it would
be confusing if the tool behaved differently depending on the state of
the document (rather than merely current selection).
Bug: T71727
Change-Id: Ifbbfa28548de9c0435c5174fb7762079f59bac54
Add a dialog to group the possible citation types and allow the
user to choose the right citation dialog for them.
Depends on Ibf29417 in VE-core; useless without I3d9caef in VE-core.
Bug: T62768
Change-Id: I22a64265475b1b4c94b46c5af196bd08331a05e7
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 turns out there are events bound to the rendering of CE nodes that
prevent certain events. The quick fix is to just round trip the
reference rendering to through the browser's HTML serializer and
parser, but T92583 has been filed to find a more general solution.
Bug: T92427
Change-Id: I725a0d2dbb24af9cbe7b1e7e0c8e0bda7fd8417c
Since all transclusion nodes can be interacted with (including the
'hidden' ones,) there is no need for MWTransclusionMetaNodes.
Change-Id: I23d37e3d82029b7475ec68ebb04883c7e05370cc
ve-ce-surface is a child of ve-ui-surface. The ve-ui-surface has
margins that would remain in the document flow causing a temporary
growth outwards to the bottom during deactivation (causing the
white area and blue border on Vector's grey background to move down)
after which it would restore again.
Follows-up 77f016a.
Bug: T91442
Change-Id: I5b999b580c968fcd24f07d9a895cfa17afc80c0d
By removing from and re-inserting into the InternalList when the right
attributes change, rather than trying to hack it into the model's
updateInternalItem (which won't get run on undo).
Bug: T71119
Change-Id: Iaf7a3127576b94666e05691902d2782394d24afb
Since Bug T90654 has not been addressed in two weeks, I would
rather make the test pass, assuming that the slightly altered
diff view is a feature not a bug.
Change-Id: Id2ce34b2838cf56a9411173f9b2e9ad8e5320545
