These aren't supported by VE-MW, so must just be
garbage from a browser plugin, possibly Citavi.
Bug: T200971
Change-Id: I9f34e9890e7f59d76cd464778481c415cc3c5dbd
* Pass the page title, so that links to section point to the current
page rather than "API"
* Make all links open in a new window, instead of producing a warning
about losing your changes
Bug: T208978
Change-Id: Ia1924e1af644ee41ebcaa1da40ca004cb72dcdaf
New changes:
73a231157 Only handle document selectionchange events when focussed
083272487 Localisation updates from https://translatewiki.net.
b5f36f1ea Localisation updates from https://translatewiki.net.
6a2233f68 Workaround native selection bug for number inputs in Firefox
Bug: T209646
Change-Id: I78fc21e88ead9ff6e181e1a88f3f0ddbdcd8e4d8
* Use ve.getProp
* Use .abusefilter key instead of string search (the key
didn't exist when we first implemented AF support)
* Move AF handler next to captcha handler, and comment
both as should-be-moved-to-plugin.
Change-Id: I171d63844b84b5a12396b6d6746f92110fc06c6c
When an edit notice is passed through from the API, allow
a type to be specified, and specify type 'block' if the
notice is a block notice.
If VisualEditorTrackBlockNotices config is true, track
when a message with type 'block' is shown.
Bug: T209633
Change-Id: If5fecc2c2c1c39f4b7245b9a215e1120c93b2b22
Tracking is behind $VisualEditorTrackBlockNotices config flag
which is set to false by default. Additional data will be logged
into a different bucket on the client and both metrics will be
considered with their known limitations.
The reason behind this is to get an idea on how frequently blocked
users attempt to edit a page. Similar tracking is being added to
MobileFrontend and mediawiki/core.
Bug: T201718
Change-Id: I51576276b97be0716c2c22348eaa756ffb04fe50
I have moved this block of code to the wrong place in change
13675e4a81. As a result,
`this.loaded` was being set early, so the dialog was treating
all of the pre-existing transclusion parts as newly inserted,
and the "Apply" button was therefore always enabled.
Bug: T209661
Change-Id: I3c1b45f91738ab6fc4a6f6d61ae5bf925c9a1bb5
Undoing the changes to an image caption or alt text, or to the gallery
caption, or to the order of images, or removing a previously added
image, will now disable the "Apply" button again.
The following cases will *not* disable the button again, and it is not
feasible to implement them:
* Re-adding a previously removed image with identical options
* Changing any caption to the old value by other means than "Undo"
* Changing image caption or alt text to the old value after switching
to a different image and then back
Bug: T206534
Change-Id: I7c19600e741211a6ba61837513497facbafc5cef
Use 'change' event instead of 'reorder' to respond to this event.
This also covers removing images now, so delete that code.
Bug: T206534
Bug: T209451
Change-Id: I9eda383be2ca7f02b42814d43e6b42961b9b96e7
New changes:
9c4d8f893 Place popups instead toolbar.$bar
0a1dd51e8 Only attach scroll listeners is toolbar is floatable
a8e07e026 Convert remaining $.Deferred() to ve.createDeferred()
Bug: T209192
Change-Id: I08328ca5f6aadad7db069dcd81734e1932e616e7
