Collapsible relates to the Vector menu behaviour where an item
is moved into the dropdown menu if the window is narrow.
This should only apply to the secondary tab when there are two tabs.
If there is only one tab (non-VE, e.g. in a non-VE namespace) then
this tab should not be collapsible.
Server-side code handled this correctly, but client-side was
adding the class unconditionally.
Change-Id: Iecd195e92f43fe9f11b3938a1a24caed7b331e5f
Anything with type=checkbox is coverted, and its label is found,
either by for=id or by finding a wrapping label.
All other inputs are stored in $otherFields for form building.
Bug: T86617
Bug: T70572
Change-Id: I94376fef18d02d2058bb548c11ae17f3dec7268c
* Rename the actions toolbar the 'pageToolbar', and place the save button in
its actions section.
* Inject the title amongst the pageToolbar tools, so we can have tools either
side of it.
* Don't use the hamburger icon, as this has a (different) expected behaviour
in MF. Replace it with a back button, and move the edit switch action over
to the right in an 'advanced' group.
The toolbar is back to being laid out like the source editing toolbar in MF.
Change-Id: I4e00a8cdf603968ee32872323c88e587c1e1a487
We were setting the edit summary box to the contents of the 'summary' parameter
every time the save dialog opened, but actually we only want to pay attention
to that the first time the save dialog opens.
Bug: T108329
Change-Id: Ic7b456ca8d7dd7cef8bc27629e3655ce9b97e755
New changes:
2464397 Move toolbar floating code up to the target
11bdc21 Separate SA target into Mobile and Desktop
7ab3389 AlignableContextItem: Fix styling in mobile
758619f CONTRIBUTING.md: Update file paths and build instructions
Local changes to mw.Target to handle toolbar floating.
Change-Id: I0751817e3a6668b120134bfcb6c611b121a46501
Also use named classes for hiding toolbars, and move the
MobileFrontend overlay z-index hack out to that repo.
Depends on Ia46e6b4d7a in MobileFrontend.
Change-Id: I0e1f527446fd10fde5dd3107e6467fd2c8f621b2
Split the toolbar into two modes depending on if the surface is focused:
* When unfocused, show a hamburger containing back and source switch
* When focused, show editing tools, and a check button to unfocus
For the editing toolbar, space the tools out using table-cell layout
and hide labels below 480px.
Depends on I06813e3ff in core (surface blur method).
Bug: T93325
Change-Id: Ibf09cb29019d7a71e1e144b326710b1f6506cd0c
* On save, VE will now fetch and append modules and jsconfigvars to the save
event, which respectively contains necessary JS config module data and the
list of required modules to be added on the page.
* The jsconfigvars are now properly added to mw.config on edit save.
* If any new modules are now required by the page after an edit, they will be
loaded by ResourceLoader through mw.loader.load.
Change-Id: Ib3990078a22ad9e46debf3ce174e7cf27b86d944
When you bind to your own events you're probably using the wrong
design pattern.
The events are kept (without arguments) for the purpose of tracking.
Change-Id: I6983319f9e0ca179e609afb00c821e3eab2161c9
Allows us to rename onSaveEvent back to onSave.
Before this change,
* ve.init.mw.Target.prototype.save ->
* ve.init.mw.Target.prototype.onSave, emit save event ->
* ve.init.mw.DesktopArticleTarget.prototype.onSaveEvent (or MF equivalent)
With this change,
* ve.init.mw.Target.prototype.save ->
* ve.init.mw.Target.prototype.saveSuccess, emit save event ->
* ve.init.mw.DesktopArticleTarget.prototype.onSave (or MF equivalent)
Change-Id: I016262b38a941c93c0978391491baa6d5a32fe28
* Make save a FragmentDialog and open with WindowActions so
the selection is restored automatically.
* Pass in some information in setup data.
Change-Id: I254b71f252adce064b9c2d2bf2cb6c8d0018e31f
MW target has 'static' methods, some of which aren't attached
to the static property, the rest of which should be instance methods.
Rename success/fail functions to remove 'on' as that is reserved for
actual event listeners.
Change-Id: I63e68dbe1923906208b180abfc4a9a280b4d098e
* Use local edit source tool, and emit event to MF
* Bring in toolbar styles, bonus: remove old desktop style hacks
Bug: T96186
Change-Id: I89351e409aa4e9d626edd7151ae05bdcd58f1cee
New changes:
11953f7 Localisation updates from https://translatewiki.net.
0dbafb0 Update OOjs UI to v0.12.2
cbd0982 Replace placeholder color with opacity
087365c Support other types of 'empty' document placeholders
7692890 Make scrollIntoView a VE utility function
5a1a159 Localisation updates from https://translatewiki.net.
8edf71e [BREAKING CHANGE] Kill ve.indexOf and thus @until
bb02b02 build: Bump various devDependencies to latest
cb5b2cd Fix scrollIntoView util binding
8feab4e [BREAKING CHANGE] Use config object for Target constructors
Local changes:
* Use config object for Target constructors
Bonus:
* Add CSS classes to MW targets
* Use 'super' calls
Change-Id: Ieb4e4eb3663aab2706c0f3ecc8b82e00555df1d5
* Bring in back button & save button from MobileFrontend
so they are properly styled OOUI widgets
* Accordingly, move toolbar save button code up into base
MW target.
Bug: T96186
Change-Id: Ic89dd4efb831fc3b09980da16524276f6568619d
This reverts commit cb11cbd2f5.
Actually not needed after 3d36cac7fc4808f708f03b66f5c099de440e4569
in OOjs UI, and would change the UI in unexpected way.
Bug: T103403
Change-Id: Ia30b168ea29d03aa76ad81d1f9894a67604fdc08
When loading VE by clicking Edit on a view url, this naturally
works (we temporarily append our query, and remove it when ready).
When loading VE from a permalink (e.g. Open in new tab) or any
other source linked from HTML pages, then we're not in control
over adding the query (it's already there); we're only in control
over restoring the view url afterwards.
Bug: T102363
Change-Id: I4912ff1c6b28ac987517760ffed481a4cd3bd1ca
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
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
