Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.
After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.
(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).
Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.
Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
The ...target.wt property contains the wikitext used to generate
the template name. It can contain trailing newlines (T234817) and
all kinds of funny wikitext syntax. Instead, use ...target.href,
which is the title of the page that is actually transcluded. Compare
the new code to ve.dm.MWTransclusionNode.prototype.getPartsList.
Additionally, fix some confusion about namespaces (treating template
names as titles in the main namespace). The template names in the
configuration page (visualeditor-template-tools-definition.json)
now support overriding namespaces in the same way as in wikitext.
Bug: T234817
Change-Id: I7c557d28e961d0b9117fc0380c65cdd42035ae96
If you had an image thumbnail for a file 'Foo?.png' on the page,
ve.ui.MWMediaContextItem and ve.ui.MWMediaDialog did not escape
the '?' when linking to it, which resulted in incorrect links.
Similarly, if you had an internal link to the page 'Foo?',
ve.ui.MWInternalLinkContextItem did not escape it.
Additionally, the links were always generated as if the wiki was
using short URLs, even when it is not (T233628).
The approach using mw.Title is copied from ve.ui.MWGalleryDialog.
Bug: T233628
Change-Id: I10256ed6883dae0ea216de4c0719f03d7fd19ae4
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute, and parse 'resource' to keep it
identical to 'href' if they refer to the same page (including
same percent-encoding and space/underscore). This resolves Parsoid
generating |link= options for copy-pasted images (T193253).
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: If2d7f080d9d693568054f8311c1e1b15ca27ea5c
* Handle mw:MediaLinks pointing to to non-existent files, which come
with typeof="mw:Error" (similar to image nodes).
* Fix regression from c66f8e0547, which
caused all mw:MediaLinks to be treated as plain external links again.
* Add test cases.
Bug: T232754
Change-Id: I9ae5bcfc4e24e8c0d22ef77d6a4d03f817fc9768
In order to get the desired padding, the `em` values were pre-multiplied
by the parent font-size, which was assumed to be `0.875em` for normal
surfaces and `(13.3333/16)em` for wikitext surfaces. (That should have
been `(13/16em)`, by the way, but that's a negligible difference.)
Unfortunately, the font-size for wikitext surfaces is actually `13px`.
Unlike `em`, `px` values are not affected by custom browser font-size,
so when one was set, the final padding was all out of whack.
Use `rem` units instead to respect the custom browser font-size,
without getting problems due to the parent element font-size.
We don't need separate rules for .ve-ui-mwWikitextSurface now.
Bug: T222217
Change-Id: Ib7ffbf09d5aa23fddb894aa3b081ec993ddcee2d
This meant we were returning invalid documents with bare content outside
content branch nodes. Instead let ve.ce.Surface in VE core do the unwrapping.
Bug: T232944
Depends-On: I8799d51958b966c99307f4c70546ea326e67385c
Change-Id: I0479116b51cc3135a992fdf36b8edfb2c44916ba
The call to selectFirstContentOffset() below would re-activate the
surface and (attempt to) show the keyboard if the surface was
deactivated, but not shown as deactivated.
This might have worked correctly by accident before
I39fe44eee8eab7129340bcff796b6b9b3a59a398 in VE core.
Change-Id: I500309cc0aa8cd794175ae683a17c2614fd58cc9
Some post-save scrolling would try to access the view before the
handlers were cleaned up.
Bug: T232347
Change-Id: I30433ef027c52d541351972f8ebb09fe6d45e436
As of I6c043e039fbef62a56f475b0dc365e171ab7bf59, this method is never
called. It was previously used to update the size of the toolbar when
context menus were displayed inside it, but they are now displayed
elsewhere.
Change-Id: I53030de1203a7f0d75780ae796bbb10082d5ef7a
As of I2f2495ab6c10116a6660f4361e49272cb95b988a in MobileFrontend,
the overlay never uses the default spinner.
Change-Id: Ie0aa624e33a5bd21fc20459697cca175d9de5606
New changes:
d4cb2f03e Update OOUI to v0.34.0
b0b481693 jsduck: Stop listing OOjs in upstream, it's using JSDoc now
0b17a137b Update OOjs to v3.0.0
Change-Id: If29a97ce689523763431face5a13929a461735b4
The good thing is that every time our CSS overrides get less crazy.
See 75ff121b29 for the last time.
Change-Id: I9d81aff6a24ec28850563e00206e21c4a6593d2e
Context items can be created for specific template titles. Titles
are mapped to context items using an on-wiki message.
Bug: T211243
Change-Id: Icfc39e350452da238d0e0c17cb2305c60d9ca16a
Tapping the toolbar save button while the save dialog is open triggers a save
because of the accesskey. It shouldn't save on a double-tap, because that's
easy to accidentally do / trigger on a slow device.
Bug: T230816
Depends-On: I4c3afce9d57c9bca737272b40b9a4862b5794bac
Change-Id: I1925b1b97de6a811f73196b616ec09a2c30c336f
Depends on MediaWiki change I48d4bb3f, which adds the 'arrayParams'
option to handle explicitly indexed array parameters like
`&preloadparams[0]=a&preloadparams[1]=b`. Previously we only handled
implicit indexes like `&preloadparams[]=a&preloadparams[]=b`.
Bug: T231382
Depends-On: I48d4bb3fdf0ea7f5eb133c59bf63651ba356fc42
Change-Id: I8c899bce1b19fa286bd385f89e102a4b87db4db3
The double result creates more confusion that it clears up,
and now that the query input is always used for text insertion
it is less of an issue that we don't have a case-exact match
in the results list.
Bug: T230819
Change-Id: I58cbe740fa7d0327aadd5dd111161bb7087a4ddb
New changes:
77076f828 LinkAnnotationInspector: add a "label" field on mobile
Local changes:
* Updates for mobile link label editing
Bug: T229431
Change-Id: Ib0489f6f59b228ebc4a20f7a0a515be938a8f6d3
When saving fails for a reason we don't handle explicitly, the error
message will have HTML formatting and will respect any on-wiki
overridden messages, rather than being plain text generic message.
Extensions providing custom SaveErrorHandlers may need to be updated.
The only one in Gerrit that requires a fix is TitleBlacklist:
Ibeae79c95557a7af699716c9d921f34c310bee6d.
* Remove handling for errors returned in .visualeditoredit.edit.info
rather than .errors (.error in old format). AFAIK this is only used
by some extensions, it is probably incorrect to do (T229539) and all
extensions I know of that do this (AbuseFilter, SpamBlacklist,
ConfirmEdit) have custom SaveErrorHandlers.
* Remove custom error messages for 'readonly' (identical to API
response) and for 'hookaborted' (very unhelpful and there is a
chance that the API response is better, if the extension causing
this error generates any error message).
* Add a silly shim for MobileFrontend integration, because we allow it
to handle error responses, and it expects them in the old format.
This is probably subtly wrong in many ways, but MobileFrontend code
only uses this for logging, so it shouldn't explode. In the future
we will hopefully change it to use errorformat=html (T228897#5366960).
Bug: T229532
Change-Id: I3b9c4fefc0869ef7999c21cef754434febd852ec
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
New changes:
62f06382c Localisation updates from https://translatewiki.net.
5fc25c0d9 LinkContextItem: Apply ellipsis directly to link
Local changes to fix link ellipsis styles.
Bug: T230267
Depends-On: I25bb4fa9b7288232b08bab9c88f281817a26d6bb
Change-Id: I8a4b04d45979a1f6c375a7c92a340e3e81d7753c
The .oo-ui-popupToolGroup-handle styles only need to apply to the
editTools toolbar, where they override OOUI styles so that our
"stretched" toolbar works; they don't need to apply to the pageTools
toolbar, which contains just the editor switcher, and where they make
it look different from the MF wikitext editor toolbar for no reason.
Change-Id: I21315b34be0a7c3938f84ada720ff5754d953879
We were incorrectly always adding action=edit to the URL in that case.
The condition was always passing because `this.section` is `null` when
unset, but `this.currentUri.query.section` is `undefined` when unset.
This is a similar fix/bug to a68cc38b22.
Bug: T209163
Change-Id: Ic80ac377b763aea53678c4209ba6b3a6ba2996c9
As detailed in T95850#5078990, Parsoid incorrectly converts HTML to
wikitext when a link `href` refers to an interwiki page and contains
percent-encoded colon characters ':'. VisualEditor doesn't know
anything about interwiki pages (it treats those links as normal local
links, and expects MediaWiki and Parsoid to handle them specially),
so we can't easily special-case them. But since leaving the colon
unencoded is valid for all links anyway, we can just do that.
Bug: T103635
Change-Id: I87d7e6952983a72d90ea739b0bc8488d9f6a9be3
New changes:
854a1fa2c Distinguish active link styling
Local changes:
* Pull through active link styling
Bug: T228220
Change-Id: I925f88d32a514a749b96f501a211003bc4c924f0
New changes:
28aea2e4d Edit cards v2 design
739017973 Track usage of the new "close context" button
Local changes:
* Edit cards v2 pull through
Bug: T222396
Change-Id: I1ca885e8d8127e7827a059755315ed789a7b9210
Since we're inside the Target instance, `ve.init.target` refers to
this object. Some of the code I'm changing even uses `this` instead
of `ve.init.target` on the next or previous line.
Most of the mistakes are a result of mass search-and-replace changes
(478b0bcb, e1a887cc), or moving the code from other classes (d294006d).
But I can't explain the "ve.init.target.getSurface().getDom()" line,
it would be good to figure out why it was this way before we change it.
Change-Id: I0d7c6a48369242d4c99620fcd775ab537420d84a
New changes:
a06204317 Fix TableNode unit test getOffsetFromCoords failure on Firefox
dfe0eb025 Refactor mobile context logic into ve.ui.MobileContext
Local changes:
* Pull through for edit cards refactor
Bug: T227532
Bug: T228767
Change-Id: I6c043e039fbef62a56f475b0dc365e171ab7bf59
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
We also show this dialog on the old wikitext editor, where
ve.init.target is not set, because the relevant code is not loaded.
Follow-up to 478b0bcbb9.
Similar to e88cd81f94, which fixed the
same issue in a different file.
I checked all uses of ve.init.target in files under ve-mw/init/ and I
think this was the only remaining mistake.
Bug: T228684
Change-Id: I15551870cdb01d570e24ba9668e67330b8072e01
Our overlay could be higher than the viewport, allowing the viewport
to scroll again.
Bug: T212159
Change-Id: I1e97d1963b214fc7673c33ae6c14ab7b0b80f31d
Since I7f6fd7ee9 it is now possible for the options bar to be
completely empty if the user is logged out. In this case hide
it and only show it again when the character limit needs to be
show.
Ideally we wouldn't have the height change, but it is quite rare
that a user gets to 400 chars and is logged out.
Bug: T228165
Change-Id: Ifbdf352afcbf4e549889e04fdb70fd30ce233aad
Turns out we had this message lying around unused,
so use it (even though an invalid title is quite
hard to come up with).
Change-Id: I0200678820fe88a59869f7fad8f491b4c5b77482
There are cases where the page title and the real/desired page name
are not the same. Fixing that also fixes the suggestions that appear
in dialogs (see related bug).
Bug: T193132
Change-Id: Iafa84c05bea08ebb061ee6d1323eb50945b39815
When previewing/reviewing changes, the "Return to save form" button
now replaces the "Resume editing" button in the top-left corner (and
receives the 'back' flag). Effectively, you tap 'back' once to go back
to the edit summary, and twice to go back to editing. This seems to me
like a much more natural interaction than two separate buttons.
Bug: T225021
Bug: T227049
Bug: T227857
Change-Id: Id27ccf06923c8aa86b1c1a9292bc43bb825ce6c8
