* Make inserting secondary tab work with Minerva's non-standard structure
of navigation menus
* Distinguish primary and secondary tabs with tiny icons, since Minerva
hides their text
* Hide section edit link dividers (unnecessary when we use icons)
Bug: T208102
Change-Id: Ieaec60165617e3b423ec58857d6f0a0406e22b1d
Our behavior is now closer to the core wikitext editor.
This results in two minor changes:
* `<li>` elements are now correctly wrapped in an `<ul>`.
* "View full log" link is now only shown if there are more entries.
Change-Id: I3f30446fca5cab83155ce26ee4e5ab213fc5847a
New changes:
a190a64ab [BREAKING CHANGE] Do not cache document model data in DM selections
866f48853 Localisation updates from https://translatewiki.net.
Bug: T208228
Change-Id: I2c759ab5e390f3d29070509738191df8995ccf0a
New changes:
a2dff3032 DesktopContext: Don't rely on selection#getDocument
4c1cc1640 Basic test for WindowAction open/close
0ab1e754c Update OOUI to v0.29.3
a8d96b850 Localisation updates from https://translatewiki.net.
b4fa3d230 ResizableNode: Add test for updateSizeLabel
caf188be0 TableNode: Test basic mouse events
Bug: T208228
Bug: T208382
Bug: T208515
Change-Id: I0db7b5e874ad6b23dad1f29bb1a58e126fea7a48
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
Now when using the MonoBook skin, the text size for headings inside the dropdown is the same as their size on the page.
Bug: T72559
Change-Id: Ie0c30369021f8022b788730a6de90e44a288b13b
This way users can rearrange/edit current name without exiting VE and/or copying it from somewhere else
Bug: T145339
Change-Id: I80690cdf344c2ccbdd8be486642afcf841f36c10
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
