Many of the details of the behavior don't really matter, but
I suppose it doesn't hurt to document them.
We really want to test two things:
* When converting from DOM to model data, a <mwImageCaption>
or <mwGalleryImageCaption> is always generated, even if
DOM has no caption.
* Model data that doesn't have <mwImageCaption> or
<mwGalleryImageCaption> is nevertheless still valid and
converting it to DOM doesn't fail.
Follow-up to Ie82fb339f6bd8ae1b289235bf5402490722d9a7c.
Change-Id: I0a10351e9c1589afbee76d8a85f869987de3de22
New changes:
fa5d35054 Only re-use session token if docname matches
58d7cd280 Localisation updates from https://translatewiki.net.
d0716d8e7 Update files generated with new l10n language 'my'
2cc7a4423 Create unit tests for sequences
873fdd01e Upstream horizontalRule sequence and fix command
Local changes:
* Register unit test file for sequences
* Remove duplicate horizontal rule sequence
Change-Id: Ibc65cf5c086428bb0d13c8e2f2de5819e1e23d43
This padding needs to come out to an exact integer pixel value (14px),
otherwise things are off by less than a pixel and look ugly: F24664180
1em = 16px
0.875em = (14/16)em = 14px
Bug: T190596
Change-Id: Ieb292ed14e0b9205d15254667e97613fbf339260
Refactoring in 92c4e23 didn't account for the case where there are multiple
tabs and source mode isn't NWE, which caused the "edit source" tab to just be
a page- navigation that always discarded changes. onEditTabClick handles this
case fine, so just always bind the handler.
Bug: T199655
Change-Id: I3dca87a7a3b0ea88ef0008be89cd1f6007167916
While all of the following are valid in the model:
1. <mwBlockImage></mwBlockImage>
Image with no caption. Must use the media dialog to insert one.
2. <mwBlockImage><mwImageCaption></mwImageCaption></mwBlockImage>
Image with empty caption. There is a slug to insert a paragraph.
3. <mwBlockImage><mwImageCaption><paragraph></paragraph></mwImageCaption></mwBlockImage>
Image with caption with empty paragraph. Nice and intuitive!
(Same for <mwGalleryImage> / <mwGalleryImageCaption>.)
The third option is the most convenient for the user. We should always
generate that when converting documents from HTML and from the editing
tools (MWGalleryDialog, MWMediaDialog/MWImageModel).
Previously, the editing tools generated option 2 if no caption text
was entered, and the converter generated option 2 if there was no
caption node or if it was empty. Curiously, option 1 was never used.
Wikitext for manual testing:
```
[[File:Foo.png|thumb]]
[[File:Foo.png|thumb|]]
[[File:Foo.png|thumb|Caption]]
<gallery mode="packed">
File:Foo.png
File:Foo.png|
File:Foo.png|Caption
</gallery>
```
Bug: T200387
Change-Id: Ie82fb339f6bd8ae1b289235bf5402490722d9a7c
* When ve.ui.MWLinkAnnotationInspector is being initialized,
internal and external annotation inspectors are hardcoded to
new ve.ui.MWInternalLinkAnnotationWidget and
new ve.ui.MWExternalLinkAnnotationWidget. Make this creation
more flexible by creating these inspectors through a method,
which inheriting classes can override.
* In ve.ui.MWLinkAnnotationInspector.getAnnotationFromFragment,
factor out the creation of link annotations, so overriding
classes have the ability to provide different internal and
external annotations.
* In newFromTitle, static method of MWInternalLinkAnnotation,
creation of `element` isn't flexible for reusability with
slight changes to attributes passed to the constructor. By
factoring out the creation of attributes, inheriting classes
can reuse the existing structure and alter the attributes if
needed.
Bug: T195064
Change-Id: I2037464a7be77783837e9810691c8e372c8197c6
This is similar to the hack in ve.ui.MWMetaDialog, except uglier :(
We already explicitly focus the right field in the ready process.
I am not really sure why the focus change causes the issue, but
preventing it definitely fixes it. It would make sense if we changed
the value of the field after focussing it (as setValue() restores the
validity flag cleared by onFocus()), but we don't seem to do it.
Bug: T199838
Change-Id: Ia602551ee0b0885cefbd4cb2fc00d569ff42da67
The #getReadyProcess method should be used pretty much only to focus
a field inside the dialog after it is opened. It runs after the window
opening animation finishes, so if you add stuff to the window here,
that will be visibly delayed.
The #getSetupProcess method should be used pretty much for everything
else that depends on the opening `data`. It runs before the window
opening animation, so if you add stuff to the window here, it will be
visible while animating it.
Bug: T185944
Change-Id: I71ea5b6e1e1947c1cf8fd749100e854953a8ef3c
The linkCache fetch can push the categories out of order unless everything is
already in cache. As such, remember the initial order and enforce it after the
promises have resolved.
Bug: T197759
Change-Id: I9ea8d5e642f62c96475d0713f2c79258abb33b19
I.e. don't sort them, because they're provided in source order and that's all
we need.
Bug: T197759
Change-Id: I3b9508ff49233ccfbeba1d111a6df9f29f0fc318
We relied on some white space baked into the background-image
to "reserve the space" for the text. If we tried to make the image
smnaller, the text would start overlapping it.
Remove 100px of vertical white space from the image files, adjust
the styles so that text is displayed below the image rather than
overlapping it.
Bug: T191095
Change-Id: I2f19128a2044b3505cdea93c3f587fe62553071d
