VisualEditorFeatureUse as feature: notices, action: show.
This doesn't distinguish between the automatic on-load show and manually
showing them from the toolbar.
Bug: T344465
Change-Id: I5a0d7e87592c286afe51e02ae8436f7d2ce71021
I apparently forgot to pass the parameter to fireHookOnPageReload()
that I introduced exactly for this purpose. As a result, the basic
post-edit popup appeared, but the temp user popup did not.
Also rearrange code so that fireHookOnPageReload() is still called if
we need to redirect to complete creation of the temp user.
Bug: T344879
Change-Id: I36c64f27d2b8866ca88642621a135e7e25a91ce1
Abortable promises are definitely among my least favorite things.
It takes all of this bookkeeping to make .abort() work consistently
(so that it always aborts a request if one is in flight, and always
causes the final promise to be rejected even if we didn't start a
request yet or it has already finished). But, if you squint and ignore
every line with the word "abort", it's like a normal promise chain.
Depends-On: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
Bug: T331397
Change-Id: I67309c79e6d211d69630fe89cbf5402f8fbd350c
A new hook `ve.preSaveProcess` is triggered to give other code the
chance to add steps to the process. The save dialog won't show until
the process completes. A step can be failed to return to normal
editing.
Change-Id: Id0740ff58ba9d9519c81174100ef1b8f8740870b
This method was only called, and the message was only shown, when
retrying after the first 'badtoken' error and refreshing the token
fails again.
If this happens, it usually indicates some terrible problem with
the wiki, and it is not something that can be fixed by logging in
again (or anything else the user can do).
Let the default API error message appear ("Invalid CSRF token.").
While not very helpful to the user, it should be more helpful to
the site administrator trying to unbreak their wiki.
Remove the "visualeditor-savedialog-identify-trylogin" message.
Keep "visualeditor-savedialog-error-badtoken", which is re-used
in another error message. I'll fix that separately.
Change-Id: Ib680218bce5ae38aa52d7d941218a6410ab7e09e
This has not been used for many, many years, since we started using
mw.Api#postWithToken, which automatically retries on 'badtoken' errors.
Most of our code for it was removed (e.g. save() is never called
with three parameters), but some comments and parameters remained.
Change-Id: Ibca2a222f808e6e2796ed6a61e9587a646afcf31
Occasionally we end up logging error codes like
"abusefilter-disallowed,abusefilter-disallowed,abusefilter-warning"
when someone hits a bunch of different filtes.
Change-Id: I967d374d13473ca684412b380d732653a3ceaff3
TODO comments suggested using the VE helper util, but
that is no longer necessary since all our browsers
support passive events.
Change-Id: Idb7e702d58931208d555a3f994cd0b73abec2e20
This makes it easier for 3rd parties to insert extra tools
in sensible places.
Change-Id: I6c8d0c96f53655d8f9ae9f01e5d0e1a1678d29a1
Depends-On: Ib8882fa6319915d291b345a69ab95f362739ad7b
This affects logging behavior -- notifying WikiEditor lets its logging
clean up after itself before the init event for VE fires. This was only
an issue when switching *with* changes, because that path resulted in
the timings being cleared, making future events whose timing depended
on the init event have NaN timings.
(This wasn't an issue before we centralized the logging code into
WikimediaEvents, as before that WikiEditor and VE were maintaining
separate timing registries.)
Bug: T237063
Change-Id: Icdb307fa0ce0d1dac3744e4bab41b3588f14777f
Instead of passing a "teardown callback" to a specific dialog,
run the command as usual and clear the loading message once
the dialog has successfully opened.
Change-Id: Icacabb298f1a0d7a587ab8b992759b04ff59c5c3
