The linkCache fetch can push the categories out of order unless everything is
already in cache. As such, remember the initial order and enforce it after the
promises have resolved.
Bug: T197759
Change-Id: I9ea8d5e642f62c96475d0713f2c79258abb33b19
I.e. don't sort them, because they're provided in source order and that's all
we need.
Bug: T197759
Change-Id: I3b9508ff49233ccfbeba1d111a6df9f29f0fc318
They look like they should also apply to Flow, ContentTranslation, etc.
And apparently CollabTarget was already loading them separately.
Change-Id: I5c502f8e060968ecee67567747f29eb630cda718
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
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
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
Besides redirects, API can return from-to title pairs for normalized and
converted titles, as well.
Currently, doing an API query on eswiki for page info (prop='info' in params)
with titles='User:Title' returns normalized title 'Usuario:Title'.
processResult() method in ve.init.mw.ApiResponseCache.prototype.processQueue
sets page.title ('Usuario:Title') in cached results, and the promise for
actual queried title ('User:Title') gets rejected in rejectSubqueue() method.
Change-Id: I33fd4640b6eac8018e35c6fe21234f4c469dd97d
In Schema:Edit, all action timing durations (ready, loaded, saveAttempt etc.)
are defined as "time since the editor was initialised", which is internally
stored as the timestamp for the "init" action.
The 'init' action itself does not have a timing duratation, but the Edit schema
has a special case for it, definining it as "time since the page was loaded".
In actually, it isn't actually implemented as "time since the page loaded",
and I suspect that as such, this value is probably not used by EventLogging
consumers of the Edit schema. Or, it might be used, but doesn't represent
what the consumers think it does.
Presently, it uses the init time now() - mediaWikiLoadStart, which basically
means the time between the random point at which MediaWiki core JavaScript
finished executing which is quite variable in practice due to the race between
<script async> and browssing parsing/rendering of HTML. That is by design,
and is also why mediaWikiLoadStart is undocumented and internal, and actually
in the process of being removed.
After many iterations on this patch to try and approximate an alternative to
this undocumented variable, I came up with an alternative approach with DLynch
at the Hackathon, which is to simply not record this one timing value, but
preserve the behaviour of all the other timing values exactly as-is.
That is, keep the behaviour of storing `now()` as "init" when the editor
activates, and keep the behaviour of substracting "init" from all other action
times, but only don't report "init" itself to EventLogging (given its value
would be 0, which isn't useful).
Bug: T160315
Change-Id: I778234efe40dde8ff30333339335be1c3910a4e0
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
If the mediawiki Api pass redirects as true, the response will have
redirect data. ApiResponseCache ignores it now. This commit adds
support for processing that and set in the cache.
Change-Id: If4f8c9b6719c123b31d852eb71f06a79cc0f7917
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
New changes:
3a6d868bf Separate (Comment/Link)InspectorTools into separate files
cb5d36e32 Localisation updates from https://translatewiki.net.
c75491b16 build: Extend 'svgmin' options and amend
ddef270d9 Genericise activeLink behaviour to any annotation
d13d44e12 Create simple comment annotation type for rebaser.
7e49a1f33 Add getters for author properties
1d341ca7d Follow-up I16942623d: Only filter inactive models if they are 'canBeActive'
Local changes:
Change .ve-ce-linkAnnotation-active > .ve-ce-linkAnnotation.ve-ce-annotation-active
Bug: T185596
Change-Id: I2a49315d01aa075373f9b5f0d8802a7e7dd4dca3
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
The duplicate header, especially the duplicate elements with identical
IDs, were difficult to handle for other scripts.
Now instead of hiding the entire wikitext diff, we only hide the
"content" rows but keep the header, and adjust our attributes on the
header back-and-forth when switching diff modes.
Bug: T192755
Change-Id: I3a6bb4730fefd81f533b786ec3b20241c4cb8d13
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
