Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
These are only needed when we need to access a specific `this` from
within another `function () {}` context. This is not the case in the
situations here.
This is split from Ibf25d7e to make it smaller and easier to argue
about.
Change-Id: Ide1476de91fc343aa992ad92a1321d3a38b06dd0
We were using addItems() incorrectly, and it stopped working after
change Ib1241f93d214e8a7d2f757a120f84de3879575af in OOUI.
Bug: T299818
Change-Id: I2d00cb929673a419789ca6f8bc308721373e1da8
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
Previous, reverted attempt: da9b6fffbd.
This attempt also includes 6037fefbe0,
and fixes minor conflicts with other changes.
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute. This resolves Parsoid generating
|link= options for copy-pasted images (T193253).
Keep them in the underscore-form to avoid causing dirty diffs like
T237040 again. Unlike in the previous attempt, we don't need to be
super-careful about the 'resource' attribute, thanks to the Parsoid
changes in T108504.
* 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: I91131728a87c9406bf069d46d3c94c9a8905a003
Items which are invalid titles will still get discarded if
the gallery is edited, but this is better than crashing.
Bug: T260584
Change-Id: I5dc20c233fd9ab41bdf48531829bddca2c5b25df
Various buttons have a label on desktop, but only an icon on mobile.
We should still use the label for accessibility.
Change-Id: I2b49a80e174dc30ae997a69662643b28b428263a
New changes:
4af3f84f7 Mark surface as "showAsDeactivated" when opening a window
79eb0e4e5 ve.ce.Surface: Guard against focusing a un-initialized surface
4124c275e [BREAKING CHANGE] ve.ui.TargetWidget: Construct a real target inside the widget
Local changes:
* Use new target widget
* Remove calls to deprecated methods
* 'surfaceReady' event was upstreamed
Bug: T236400
Change-Id: I765d657c172d96c3b2e2ae5998083e4926a31f15
* 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
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
New changes:
f039957f3 [BREAKING CHANGE] Use keyed objects for importRules blacklists
Local changes: Use extendObject to set importRules
This allows us to inherit the ruleset from the parent
so we don't have to worry about keeping it up to date.
(For example alienTableCell from upstream was missing
in MW).
Media/Gallery dialogs: Add missing mwTable types.
Change-Id: I366a091ff4def66cc25200b3d1b2c23ba6b716f7
Depends-On: I8ff7e8242c8db235a0f9e11e2e52f90d62d368a0
New changes:
202adf904 [BREAKING CHANGE] Unify FragmentInspector/Dialog behaviour
Local changes:
* Update dialogs to use common actions & FragmentWindow
Change-Id: Ib744b8996db48d1ee58bc873120400566c490e88
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
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
