On iOS Safari, when the keyboard is open, the editor toolbar could
previously be scrolled out of view, due to how the keyboard affects
the viewport (or rather how it doesn't).
Detect when this happens and bring it back in, with a similar slide-in
animation as when the editor loads. Technical restrictions prevent us
from really keeping it in view at all times, and I think this is the
best we can do (and it looks almost intentional).
Bug: T218414
Change-Id: I5eed360d4644815bc9829fbc6b0ffd79b205d10b
It will be easier for us to maintain this way. The code I'm moving had
a lot of comments saying that it should be moved here.
See MobileFrontend change Ibe192360bdecab86519de1781f66f90a3441c551.
Bug: T218946
Change-Id: I908e035ec245a9b190f05e64c35dbb29936434de
It was here because our old hacks prevented the viewport from being
scrolled, so the keyboard would always cover the last few lines of
the surface. But it is no longer necessary after we ditched the iOS
scrolling hacks in MobileFrontend.
Bug: T217769
Change-Id: Iaf3f86c0fc43f75d11a43462721f44d62abc6eb3
This is no longer necessary and doesn't work after we ditched the iOS
scrolling hacks in MobileFrontend. And the default implementation works!
Bug: T218429
Change-Id: I5fba78a3877901dac5afda46d3004c07cad383d0
This enables mobile section editing if the user is logged
in and has an odd user ID. Otherwise it is disabled.
Bug: T218851
Change-Id: I2c22d7636ae11d2db7780ae5adb3abe9df532b7c
When this code was written in 2013 (1a5bdd5bd2),
the langlinks API did not have a way to return the language names (autonyms).
This has been added in 2014 (4ba3a9aea96ee21c035c69999be23580e23f4e0a).
Change-Id: I70edb846d94b1108b079caf5915532234190da8f
Passing section=undefined resulted in no <section> tags being
unwrapped, which broke the historical diff. Ensure 'null' is
used instead for whole documents.
Bug: T217752
Change-Id: Iec33e6ab83bfbd011df9dc05f4daccc26b1df8b5
Catlinks is hidden via a class when there are no non-hidden categories on the
page. We thus need to toggle that class depending on the categories
added/removed from the page.
Bug: T213528
Change-Id: I4067c5721c28041542b9ef2dbc796fbc41b1afe8
Generating the templatesUsed list is relative slow, and is only
used in an obscure part of the editor, so only generate it when
needed.
Bug: T209078
Change-Id: I1cecdad65b80c4c9b1746e752ea4b41bc0fc0037
This code, added in 703b2c2ed0 (2015),
is no longer necessary.
// Disconnect the tool factory listeners so the toolbar
// doesn't start showing new tools as they load, too
// much flickering
this.getToolbar().getToolFactory().off( 'register' );
Introduction of targetLoader (d371014e5d)
resulted in all tools already being loaded before a Target is
constructed, so this is definitely not needed.
// Disable all the tools
this.getToolbar().updateToolState();
The tools are already disabled because we set the surface to read-only
above, so this does nothing.
Change-Id: Idb162b60891cd1b961e29d2b9f62b74908f17957
Previously, we tried to keep the list of category members and the file
thumbnail, history and metadata visible while the editor was open.
I am removing it because:
* It is not very useful, as you can't interact with them (e.g. links
are unclickable).
* It is inconsistent with the wikitext editor (except for non-existent
category pages, and I'm proposing to change that behavior in T139191).
* It causes issues when other code doesn't expect the special setup
for those pages (T194068).
This introduces a minor change to the handling of normal pages: after
the save, instead of replacing all contents of #mw-content-text with
the new page content, we only replace the .mw-parser-output child.
Normally the effect is the same (it's the only child), but this could
theoretically affect interactions with other extensions or gadgets.
Bug: T194068
Change-Id: I26cc82d3e0f0d64e3f18a80d232005fc7ab3b374
Red-link metadata was added to Parsoid 18 months ago.
On long pages evaluating this information is very slow
(hundreds of milliseconds) and completely redundant.
Bug: T64803
Bug: T209078
Change-Id: I5b6c6da588301ed59fb21e1ce930f5b72db48e67
New changes:
202adf904 [BREAKING CHANGE] Unify FragmentInspector/Dialog behaviour
Local changes:
* Update dialogs to use common actions & FragmentWindow
Change-Id: Ib744b8996db48d1ee58bc873120400566c490e88
* Separate partDescription from partDescription*s* and use Array#map
* Lookup CE node class of current model, instead of using
ve.ce.MWTransclusionNode hard-coded.
Change-Id: Ief07b865b4c216dc13408b12e8a1354cd2c28dfe
Per I7c083ff57db2fce9a06688d5801149253af6f6da this was only needed
for IE 8 & 9, which we don't support now.
Change-Id: I6e093b8ea6f8304ff296bb74297a465dd7334e07
Using margin instead of padding allows the surface margins to collapse
with the margins of first/last paragraph inside the surface, like they
do in read mode. This fixes the slight jump seen in T210630#4949865.
Bug: T210630
Change-Id: I69d4d4bd9390a1007bc40cda9e78a6b3e7a1bd1d
Icon name changed from 'previous' to 'close'.
This matches MobileFrontend's wikitext editor and other overlays.
Bug: T210630
Change-Id: I5f588c65887dd2247d3f816959807f943215e0c3
If a page contains __NOTOC__ magic word, it would break the VisualEditor
with "Uncaught (in promise) TypeError: Right-hand side of 'instanceof' is not
an object at VeUiMWTocWidget.ve.ui.MWTocWidget.initFromMetaList".
The issue seems to be that we removed ve.dm.MWTOCForceMetaItem and
ve.dm.MWTOCDisableMetaItem in commit 57a06a6e75,
but the code in initFromMetaList still refers to them.
Change-Id: I857cddcc7d4aa73375357ef922591ed94d760166
We could generate incorrect links to pages whose title contains a
colon ':' and therefore looks like a fully-qualified URL.
Bug: T206231
Bug: T206357
Change-Id: Ie34694d903a6d97589cc46417f70659559494619
It does not provide any additional information, and it is long enough
that it causes the actual template name(s) to not fit on the screen on
small mobile sizes.
Bug: T209610
Change-Id: I47a995905fef5aa2cabb2b3215111de0b506e7f7
As configured on-wiki via MediaWiki:templatedata-doc-subpage; this will
probably have a few false positives, but that's worth it.
Bug: T54448
Change-Id: Id91f95b5865e151f8007a2421428aeb82b11b3fd
New changes:
6515e03e1 ve.ce.Surface: Rearrange #findBlockSlug test to check other cases
cbfdc8570 Localisation updates from https://translatewiki.net.
708ba0557 Prevent block slugs from overlapping floated elements
3703fd66d Separate the concept of a document node and a root node in CSS
Bug: T211844
Change-Id: Ia86cf9b23e561d3c32601d41c1bc5a9824e9953c
Was removed upstream in OOUI, but we require it to
show that parameters are deprecated.
Resize to fit new 12x12 size for indicators.
Change-Id: I2356de0754a2ccf09b87b152f3023282f2e37f41
Previously we passed either data.visualeditoredit.edit or data.error,
which was mostly okay since they are mutually exclusive, but it could
still theoretically conflict if both objects had identical properties
(and receiving different things could make debugging errors harder).
Change-Id: I818d916275b8451af6910ddaa7cd4d7c653085ee
This has been moved to the TitleBlacklist extension.
Bug: T211242
Change-Id: Ia15c2619e6c642b3ceb567c28f77b50ccf41731a
Depends-On: Ibaf8a37f1aaef510923bde5ed9114f1f00fff461
* Move (de)activationComplete up to ArticleTarget
* Mark (de)activate to be deprecated in the future
* Fix some properties to ensure target.edited is boolean
Change-Id: Ie34139cb68f90f34eb243f1bb964ef578e90dfb2
The timing variable is a private closure variable containing an object
that tracks the timestamps of different events in the current cycle. The
duration variable is the result of using that information to compute the
difference between the current timestamp and the relevant anchor
timestamp. For the '_timing' property in the EventLogging data, duration
is the correct value, not timing.
(This is confusing and we should probably rename the timing variable.)
Change-Id: Iff78eb0ab83c84b73ad5c8f3eb85b1c7f120ebef
Follows-Up: Ifc2135d99f4bec917dac60992098958b72c37fc6
Moved to their respective extensions
Change-Id: If463068a862cfde15ab4d250a1424c88a5229176
Depends-On: Ib1354f0404209a15194895026ff9d179d16b1900
Depends-On: I1807a5d3d99ecab2bf4545a1bab3aa3f2ae64da8
This sets the label to be the same as the default value inherited from
ve.ui.MWTemplateDialog. Looks like it's no longer needed since change
Ia8fb88d3501ffa2c26add4419da5463a926f45d1 (2014).
Change-Id: I1dd40d2428c0221dfdc79e5f34e411b127624eb6
This early return in loadSuccess() has been incorrectly removed in
b2718b186a.
As a very unexpected result of loading the editor twice in case
loading metadata is retried, the "Publish" button was staying
disabled. See the task for investigation.
Bug: T209542
Change-Id: If528afe1ca052062005937f03fe822c5c8d0958b
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
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
* 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
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
Enable the Apply changes/Done action if (i) the current contents
of the dialog inputs would change the gallery node or (ii) if the
user has interacted with inputs that alter the gallery caption or
images (including dragging/dropping or removing an image).
Bug: T206534
Change-Id: Ia6c1cc60d4f32ac66778e6973e2d400491f74128
For now this is just moving code. In the future we will
be able to make the handling of edit metadata async.
Change-Id: I7b442dfbdd890154de0e7faab1f6b0346caa8de0
