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
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
We still don't allow inserting such galleries, but we can handle them
in existing content.
Bug: T75230
Change-Id: I5d7350f00871ac295b0ebc00a633b44570347d85
The MW attributes are 'style' and 'class'. The plural
forms are used internally only to avoid JS keywords.
Change-Id: I1b7d14872aab4b6b3882d00165924fd1639e1744
Remove config option `multiline` and change to MultilineTextInputWidget as
appropriate.
Bug: T169272
Change-Id: I45565f01de76a88d64d7b0691d1e7279354f375d
A missing image should return some data to say the
image is missing, not just reject the promise.
Bug: T169337
Change-Id: Ib41a64a783c1baca88f428417c98e7fb913d14a1
Renaming CardLayout to TabPanelLayout and all connected code instances.
Follow-up to Icfe1652cc038dc131b6b855ce9b45040b8ee5178
Bug: T164903
Change-Id: I9ce4e31e390522d469e126fb3a4b05787cef7fef
It's actually a bit surprising that the only thing broken by using
OptionWidget instead of MenuOptionWidget is some missing styles.
Change-Id: I3961fedbfc61f2f17d91dc7375d47a3cdff2a257
Also disable relevant fields the first time the dialog is
opened, not just when the dropdown is changed.
Bug: T151482
Bug: T151512
Change-Id: Ic511e1832a9fcaaeaed71c1d495aecc65fdd1d3b
Make sure the button is always visible in the
gallery dialog menu by fixing it to the bottom.
Bug: T151506
Change-Id: I560b0dffbaad9e18c6f7f703cb155356470580ee
Change I94f4fadd84cd3e prevents the gallery dialog from inserting
duplicate images into the gallery dialog after one request (e.g.
so double-clicking on an image in the search widget doesn't cause
the image to be inserted twice). However, galleries can
intentionally contain duplicates of the same image, so it is
possible to make a spearate request to insert a duplicate image.
When the dialog is first opened, it requests all the images in
the gallery at once, so the above change was causing the
duplicates in an existing gallery to be dropped. Duplicates
should be allowed to be inserted following this initial request.
Bug: T150894
Change-Id: I34353bc9b8db947488474c4be52292e0a1447705
The namespace prefix before image filenames is optional
in galleries, but the API requires it. If the prefix is
omitted, add the file namespace prefix.
Change-Id: I3d126550c2ad2e84454122f92307ba4bc943780b
