No idea what causes it, but I've seen a similar issue when working on
Ic35f084d019afd1782292c831765ceb1444fb14a (in OOUI) and this hack
worked there too.
Bug: T219680
Change-Id: Ifb49ede450cabdcd8303b298b62f2ac632809b53
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
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
* 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
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
Extracted extractValue to a separate method
Added checkValidRedirect method to MWSettingsPage
Added errors when redirect address is invalid
Added 1 error message to localisation strings
Added 1 TODO (more precise error messages)
Bug: T74971
Change-Id: I8bcf16e97e5211671759acdf0846243df2c03fc2
This reverts commit be628a5b7e.
87b20f9b Revert "[BREAKING CHANGE] Do not cache document model data in DM selections"
Change-Id: I47bbf757a4ad227346d3734f6e50d928a2de1409
The initial value for the categories field is set asynchronously
(after potentially querying the MediaWiki API about the categories).
This caused the existing categories to "pop in" after the dialog was
opened (if you were on a slow network and it took more than 250ms to
query their information).
Additionally, it caused the "Apply" button to always be enabled if the
page had any categories on it (since the categories field was still
empty when extractSettings() was executed).
Bug: T207719
Change-Id: I46475a1eead91707edb8efe8cb7221a734818e16
