OOUI was effectively overriding this with it's own rule for labels in an option
widget.
Bug: T99267
Change-Id: I82ce2d5ec1a859075d7bf1010ca76cdea9ead1a0
The red-linked images in VE are now identifited as red links and image errors.
They can be changed and thereby be modified just as any other image on the editor.
Bug: T52788
Change-Id: I9cbb992c34d71b7073157fe276fee04e901845b1
* The element's class name changed.
* Zooming is removed - it was breaking the test and
it's not needed anyway.
* Fix another element with the same class.
Change-Id: I46a867619ed49936c3868f6b1b15e773bdb6f6b1
All this is no longer needed since 121216184718e7ebe22d6ecc8f5af5fe4e202465 in
OOjs UI and started causing issues after bb9c9c4f6a2fca6aed0e671e904e469d57da5f34.
Bug: T98795
Change-Id: I6493d6b52b313aac521aee2b0cff1571ea63bbe5
* Add a 3rd stage will triggers on API load
* Allow stages to complete in different order (as happens
on second load)
* Use CSS transitions
* Start slow and speed up using ease-in and progressively
shorter transitions
Bug: T95137
Change-Id: Ib9090e6c80b7a186bf353c40921d40456d90211a
New changes:
a8cf098 Fix preview widget class name
d3b7d4a Use new selectItemByData method where possible
5256021 Resolve attribute values (href and src) in PreviewWidget
Change-Id: I8b3cc0dc9a731a09f80cd3f9e4673892afdf77b0
Don't use the full IndexLayout for now as it doesn't
work easily in variable height situations.
Depends on this feature being preset in MW core.
Bug: T97878
Change-Id: I5d949bf69b0721b288c37c1f12210b0265658eb5
New changes:
68959f2 Localisation updates from https://translatewiki.net.
2c0224d [BREAKING CHANGE] Link widget refactor
f81eefa [BREAKING CHANGE] Rename LinkInspector to LinkAnnotationInspector
Local changes:
Adjust for link inspector refactor
Create separate widgets for internal and external link
annotations. Remove annotation specific logic from link
target input widget.
Change-Id: I054c3fe7ac9c61fbc3302471abd58cab89fed5a4
New changes:
1f30c3e Localisation updates from https://translatewiki.net.
1141a3f ve.ui.LinkInspector: Clear validation state of input on 'ready'
Change-Id: I3741fa00fba103ac75cc56919ccbc7387fbf8865
The toolbar.destroy() call that was added in 5c38995bd9 was
needed to destroy the dummy toolbar when tearing down VE
before a surface had been intialized. But when tearing down
VE after the surface had been initialized (e.g. exiting using
the Read tab), we would do:
* setTimeout in tearDownToolbar()
** Set toolbar height to 0 and wait for transitionend
*** toolbar.destroy() once transition complete
* toolbar.destroy() in cancel()
This meant that we'd listen for a transitionend event
on an unattached element (because once the setTimeout runs,
the toolbar has already been destroyed by the second call),
which of course never fires, so we'd never resolve the
tearDownToolbar deferred and never finish tearing down VE.
Bug: T98388
Change-Id: I504f0cb0bf13643773fc98cb18b7b380cccb2f88
By default 'helppage' is set to a full url (using Special:MyLanguage
on www.mediawiki.org). When it is set to a page name, we expand
to a url. However that url is relative (e.g. "/wiki/..") which
is not a valid external link in the "[$1 ..]" syntax MediaWiki
uses in the 'newarticletext' message.
In MediaWiki's EditPage.php this is handled by wrapping the return
value in wfExpandUrl(), we should do the same here.
Without this, on wiki's like pl.wikipedia.org that set 'helppage'
to a local wiki page, "[/wiki/Project:Help Help]" shows up literally
in the message shown to the user instead of a clickable link.
Change-Id: I2ffc35a1b255269d5b489c68eace9edafb42d8ff
