I suppose technically you don't need it if you're already on an
?action=edit page, since that will cause the editor to load as well.
At a glance nothing seems to break if it is missing (other than the
fact that there is no way to launch the editor, obviously).
Bug: T179427
Change-Id: I3c221ded302702b881857930da5dc41630680c02
ve.track tries to guess the platform, but it needs a loaded Target to do so,
and init happens before that.
Also, log a warning when this happens, in case it comes up again.
Bug: T203618
Change-Id: I35fa58a42cd247e01f3717c9ab3a10d8ea93a484
MWTransclusionNode will preserve TemplateData <style> in its generated content.
Disable TemplateStyles stylesheets in the original page content, and reenable
them when the surface deactivates.
Remaining TODO: if multiple copies of a template with deduplicated styles are
on the page, and the one containing the actual <style> is removed, all will
lose their styling.
Bug: T197563
Change-Id: Ibd8939eef7d8eb532719f4ee0ce200600449ef81
Depends-On: Ia9f2afcdba5456238e3ef444c202c9b0c78838bf
Refactoring in 92c4e23 didn't account for the case where there are multiple
tabs and source mode isn't NWE, which caused the "edit source" tab to just be
a page- navigation that always discarded changes. onEditTabClick handles this
case fine, so just always bind the handler.
Bug: T199655
Change-Id: I3dca87a7a3b0ea88ef0008be89cd1f6007167916
If the wiki runs on a host that contains a port number, section edit
links would always reload the page, and the "Add section" tab would
not work.
As it happens, my local testing wiki runs on localhost:3080.
It is an unfortunate naming mishap:
* mw.Uri#host is equivalent to location.hostname
* mw.Uri#getHostPort is equivalent to location.host
In this case, we have to compare the port too, otherwise a setup (my
setup ;) ) where one starts up another wiki on localhost:3081 to test
cross-wiki features would fail.
Change-Id: Ib7de4ba3c3a84888f24186af03bd9dcced131051
What happens when an edit tab is clicked is spread across handlers in
DesktopArticleTarget and DesktopArticleTarget.init. Consolidating the logic
into the handler in DesktopArticleTarget.init makes it easier to understand.
It could be moved further into DesktopArticleTarget, but the init handler has
to exist to activate the target in the first place.
This patches a hole where clicking "edit source" while in visual mode would
sometimes not switch to source mode, because it didn't think it was changing
the current section.
Also, fix a typo in the documentation.
Bug: T198272
Change-Id: I12d958b6af1b9fa9aca68b498eb2a1a2d76b5a82
aeb4f2f2b7 added a #wpTextbox1 to the wikitext surface, which confused our
existing teardown check. This confusion only became apparent in single-tab
mode, when using the wikitext editor.
Bug: T197615
Change-Id: I98e64e7135aaf6f8fda441a91e6cbc4bac6cea39
We already do it after save, but not if the editor is closed without
saving.
This behavior is a bit awkward for non-existent pages (redlinks),
since MediaWiki normally doesn't display them in view mode (all links
point to action=edit). But this seems less weird than not allowing the
editor to be closed.
Bug: T122388
Bug: T168338
Change-Id: Id9ee41356f011dfbfa6e8744b8d9076f8eacaf39
Not checking this results in handlers blocking click actions for "read" after
the teardown of the target.
Bug: T197445
Change-Id: I3a962c66c82a0e48ca54bf2f0b822a9a005da54c
Previously, we changed it on every load, which also occurs when
switching editor modes. That caused it to not be restored when editor
was closed.
Bug: T197490
Change-Id: Icb20c38309fd440553d5245d865b05145542313f
We were scrolling to the edited section when we saved the page, and otherwise
reverting scroll position to the top if we just abandoned the edit. This
unifies these cases, so any section-edit which leaves the editor will scroll
to the section being edited. (If section==new and the edit is abandoned, it'll
scroll to the last section on the page.)
Bug: T194631
Change-Id: Ic2aca68b3127c435545644912b96212bcfa6648d
Cite's a08febb0afa2d changed the rules for adding the Cite button to the
toolbar – it now requires a placeholder slot in the toolbar, rather than
finding the link tool and adding itself after that. As ve.init.mw.Target
was updated for this it kept working on desktop, but MobileArticleTarget
completely overrides the toolbar, and was missed.
Bug: T195191
Change-Id: I55c9de9e736bb83f5f05028f2fc07af0ad996050
Pressing escape will close toolbar dialogs (find/symbols/etc) if they're open
instead of trying to teardown the editing surface.
Bug: T190068
Change-Id: I27080649392f17344c901269029368fa0b3c2963
Override #addSurface instead of #getSurfaceConfig, so that the
$overlayContainer option only applies to the "main" surface of the
Target rather than all of the surfaces (including those in
TargetWidgets).
Bug: T194433
Change-Id: I61c609e2d52814b4547fb5292a0bfb237c4c218f
Just generate the standard wiki skin markup for categories. Adjust linkcache to always know
whether links are hidden categories. (It previously knew *sometimes*,
depending on whether a MWCategoryWidget had interacted with that category.)
Make the save dialog preview use the same method as the bottom-of-editor preview.
Bug: T194092
Change-Id: I37fea15eaef0a5847f27ce41dd92370a4bf353b6
New changes:
14bcc9256 Give toolbars groups names
Local changes:
Give toolbars groups names
Also create an empty placeholder group for reference tools.
This allows targets to specify if they should show them.
Depends-On: Iccaf35cf941cb47ad55e8d98373461f5eaff5fed
Change-Id: I0bace5e5fe05f9c214d57a74c478b48a7dcaec3b
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
When the user is viewing the last stable revision of a page which has
newer unreviewed revisions, FlaggedRevs wants us to open the latest
(unreviewed) revision of the page for editing.
Use the JS config variable 'wgFlaggedRevsEditLatestRevision', provided
by FlaggedRevs since change I4c9804fe2c4924e28770807881379ddca4fd8b76.
Also add an extra comment about loading latest revisions in general.
Bug: T165283
Depends-On: I4c9804fe2c4924e28770807881379ddca4fd8b76
Change-Id: Ic47491e690153d0ad87ce64bfc9e7a28a06fc6e2
When we set up the new section title input and possibly set its value
(preloading from URL query, or from autosave), the "Save" button on
the toolbar must already exist, because we try to enable it.
Bug: T192901
Change-Id: I3bba86a8c8a9b81014d425db256ff49f06bdaea6
Ensures that auto-save data is cleared after
creating a new article, or restoring a revision.
Bug: T192770
Change-Id: I348b8522c1a935d7db1243ba8fcbd5b24e3383a2
These are not specific to desktop.
Also make the static builders static, and move VE target specific
code to caller, such as the click handler.
Change-Id: Ib7e769e3d6d339b9e66e1bc924480b0b0d5db17d
Ensure we start with the same HTML (i.e. if an edit has
been made since the crash-recovery):
* Whenever an article target is activated, stash the initial
document html, other parsoid response data, and the request
parameters (pageName, mode, section) in session storage.
* Whenever an article is fetched through the target loader,
recover from session storage if the request parameters match.
Store transactions:
* On document transaction (debounced) append the latest
changes to session storage.
* If a document state is recovered from session storage,
attempt to re-apply the stored transactions.
Clear transactions:
* Whenever the target is torn down (i.e. save, deliberately
closing the editor to go back to read mode)
Other:
* If writing to session storage fails once, disable future
attempts for that session (assume storage quota exceeded)
* Disable tempWikitextEditor when recovering. We don't have
the transaction code loaded yet to perform the recovery.
Bug: T57370
Depends-On: I3832243fc347a99641fcb7e39a887a153c9a3b22
Depends-On: I448fb566fe9f7f5b5a76e88b70ca000e3d35b415
Change-Id: Id9d877f903cf4796a52f90991c030417a9f8786f
Allows users to know when the widget has been constructed,
and access it (e.g. to set an initial selection)
Bug: T185279
Change-Id: I3678996bcf644cc889dd168ac3ce48b5c3633ec1
This line isn't solely for supporting FF52, that is the order
in which it is called (move after attach, not before),
but that matches all our other widgets, so not sure
it needs commenting.
Change-Id: I6f3cc5687f1e4b995dff700d0765d14de1927d51
mw.storage catches errors, so we won't crash horribly when the user has
localStorage disabled / full.
Bug: T181822
Change-Id: I212994eb535b9a8fb5f6c09deaa10b16c3d7f10e
Tell browsers we explicitly want spellchecking on the section title. If
unspecified this is browser-dependent, so it was inconsistent.
This won't actually have an effect until the next OOjs-UI release (v0.24.3),
as this was a new feature added to TextInputWidget.
Bug: T179654
Depends-On: Ifdd44ead7d782288aaef0979322f0943f7304835
Change-Id: I588874efcff91c5be03da2fc03c268f883b718e2
We were reimplementing (incompletely) the setup from the .init version. Just
call the original, modified slightly so it doesn't over-setup on repeated
calls.
Bug: T151021
Change-Id: I65bd7c5ecf75c478d6babeb13e7fb2a76a9842c8
The whitelist isn't checked for blacklisted browsers,
so if all non-blacklisted browsers are whitelisted,
set the whitelist definition to all (null).
Change-Id: I8ee3569d9d5be2eda9153f1b087c1be385f93d9c
* Rename 'deactivate' to 'tryDeactivate' as it may prompts
the user to deactivate.
* Merge 'cancel' and 'teardownSurface' in to 'teardown',
extending the parent method.
* Rename elementsThatHadOurAccessKey to $saveAccessKeyElements
and move teardown to parent class where it is setup.
* Move toolbarSaveButton teardown to parent class where it is setup.
* Cleanup changeDocumentTitle
Depends-On: I9d97614695272dca6936ef6f3461178fcf0368a8
Change-Id: Ie998a04c21f6615b4415edf471310db5edca3b5a
This code is meant to fix up the tabs if wgVisualEditorTabPosition
was changed and we're seeing cached HTML with the tabs in wrong order.
But it seems it has never worked. `$caEdit[ 0 ].nextSibling` is a text
node and obviously not equal to `$caVeEdit[ 0 ]`, and vice versa for
the other case. The logic is actually correct, so let's fix it to skip
over text nodes.
Also, remove a stray 'eslint-enable' comment left over in
a0f934ed26.
Bug: T50017
Change-Id: I23663a9bfcfdbf52918452c878a128e6960b1191
Vector no longer does the silly thing where the tabs are reversed in
the HTML in RTL languages, so we must remove our hack to do the same,
since otherwise it reintroduces the issue it was intended to prevent.
This essentially reverts 2efd4f0061.
Bug: T50017
Change-Id: Ibeaa55bc34899bffab849ea8ad8b127fb5184d43
The default value of target#pageName is wgRelevantPageName
but other targets my override this, or change it dynamically
(e.g. ContentTranslation).
Also remove duplicate setter of pageName in mw.ArticleTarget,
already set in mw.Target.
Change-Id: Iebd1def1d4142978a673afec584a0b663644d176
* Tiny fix to 33dc60838c for PHP variable name
* Bigger fix to properly pass preloadparams in and split them up
Change-Id: I844db115f2563cb9ee1629c30d5f49d1ce58f5bd
This allows the use of the preload and preloadparams query parameters. They
should behave as they do in the old editor, loading substituted content in
visual and source modes.
Bug: T51622
Change-Id: I522fb5b480d17912f6d6116be6aa043ead855b52
Other page state is read directly, rather than passed in.
If we come up with a use case for passing this in at a later
date we can reconsider the best way to do this.
Change-Id: Iee7e608c969776b89dbb38b3b56a5177e48344af
This stops the welcome dialog from being displayed repeatedly if the user
edits the article multiple times in the same pageload.
Bug: T170983
Change-Id: I8cc5990e9acb1ac09a2d6dd95eef8042c70088c7
"Welcome to wikipedia, anyone can edit, we welcome all improvements. Start
editing!" is a bit out of place when what you'll see after clicking "start
editing" is "you can't edit this page".
Bug: T138715
Change-Id: I9f655a5f12d4e45644bd01631c2d3131375d8e8f
Add 'require' to eslint global whitelist for this extension,
since ResourceLoader provides this in all contexts now.
Bug: T166254
Depends-On: I0e6a95bd4fbaba06eae5137ac7af84f62bebf6f0
Change-Id: I6b2fe57317dcff18ec6d9ea0cd9e4eb9c894c169
Follow-up to fefb76eebc. Prior to that
change, the condition for this looked like this:
// … if on a ?veaction=edit/editsource page
(
isViewPage &&
uri.query.veaction in editModes &&
(
uri.query.veaction === 'editsource' ||
init.isVisualAvailable
)
)
In the refactor, the `uri.query.veaction === 'editsource'` check was
lost.
Since that code is pretty messy (probably predating the source editor
and hastily adjusted), instead change the check for `isVisualAvailable`
to just `isAvailable`. If the requested mode turns out to not be
available later, the editor will not load.
Bug: T165146
Change-Id: Idfaf9115dd20cec8f8e044a704b93b07984cdcee
Ideally we could use the preferred editor, but this breaks
tab switching to the old editor.
Bug: T165238
Change-Id: I5f5ee5566cdd2080ba7c89d43cf127b457537768
We added support loading NWE from action=edit in I35208cce069
but missed this check in the front-end.
Bug: T165238
Change-Id: I2732eaa81a3f968b34c4e878b2ad36de981dd567
Using the forthcoming wgRelevantPageIsProbablyEditable.
Bug: T165010
Depends-On: I6c6ca1cfd93e7be917952980f1e1d57aec3a1292
Change-Id: I6c6ca1cfd93e7be917952980f1e1d57aec3a1229
* Do not try to load the editor on protected pages, or if the user
doesn't have permission to edit pages.
* Move the check for required DOM elements after the check for
pages without the editor (T162411) and after DOM ready (T163307).
Bug: T162411
Bug: T163307
Change-Id: I8149694ba8155682701f2cda6ca212d60f446caa
Expanding from a single if-expression lets us make the
code much more readable, and reveals some minor bugs.
Change-Id: I49e57bfc093e019c837a73eab5c25fdbd14de0af
Previously we completely disabled the loading of notices
when switching, instead of just not showing them (so they
don't clash with the "switched" popup).
Bug: T162812
Change-Id: I3f8e787630e196cee1dbb1aa449b3558b74fcd04
This is run after the targetPromise completes (via the platform-agnostic
setDefaultMode proxy), which is the correct time to do so. We should not
do this twice, and we definitely shouldn't do this before the target has
successfully loaded, lest a user ends up with us setting their option to
"prefer" an editor that they actually can't load. Whoops.
Bug: T156316
Change-Id: Icf4b5ddd9c8265ade55f43328f807344b41db350
