No point showing the icon if we don't have the functionality to
make it do anything. Also this reduces the number of RL requests
made as we never fetch OOUI separately.
Change-Id: Iac9aa6f34c485223e73981b3377c7d0cfd31dae9
Work around RESTBase problem that causes errors if we try to switch to
VE when the wikitext is empty. This would prevent non-power-users from
opening VE entirely.
This only solves the issue for new empty pages, and not when the user
intentionally empties the edit box. In that case, though, they get a
dialog where they can choose to "keep" or "discard" changes, and
discarding lets you open the editor.
Bug: T118152
Change-Id: Ie808bcaa9826deacac392dd6cbc90a9446602b79
This wasn't as bad as T112401 (that was blocking render), but we
still shouldn't be loading the module on page views.
Bug: T118088
Change-Id: If86701ed7ff4e8d6defb1c682aa9a38c211be0fa
VE already has a a switch icon in the options menu, so bring that
up to the main toolbar.
Append an OOUI button to the WikiEditor toolbar if present, and bind
to the same functon as the edit tab.
Bug: T49779
Change-Id: Ic1e83ea7b13c4fef68024bf05ffc244060666103
Mobile target, for example, has events logged in the MobileFrontend extension instead
(which covers both the wikitext editor there and the VE integration)
Bug: T110272
Bug: T109525
Change-Id: I521f1825dc9c0a135db54cd005cda723908f14bc
We want to flip the default of visualeditor-enable to true, but don't
necessarily want to turn it on for users who already have contributions but who
haven't already enabled it. Therefore we're considering adding such users to
this autodisable preference which they can self-remove (by explicitly enabling
VE) or we can target later, separate from betatempdisable users.
Bug: T112352
Change-Id: I1ce5e6c92055e30fdc82bc912a767e913b190ef6
It's just as usable as the alien extension inspector which
is currently shown, and has better messages.
Change-Id: Ifbce9df4aff77cf76a8445158987be716ba45302
Drop beta-ness as users don't care and it confuses them. Leaving the preference
alone for now.
Bug: T99963
Bug: T112354
Change-Id: I0e039dec54d528fce24226e76b931b593dd13a9e
The loading progress would not be reset upon failure, causing issues
when you tried to start loading again.
Bug: T96437
Change-Id: I7ec4be82304c101fa1bd634f60bc6b0047e2d53d
Right now .initialize() doesn't do anything other than enable
the window resize handler for toggling the "narrow" styling,
but as a matter of principle we should call .initialize()
on toolbars after attaching them.
Change-Id: I419c943d1d20af2105b84b8f5fbccc7070af601b
* Remove page.length
* Add action.abort.type = switchnochange
Needs to be deployed at the same time as Ib99700ac
Bug: T111420
Change-Id: I7ee245157d4de6c220d7cdf54cd1dd69ff836f15
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
