This triggers Toggler.js in MF to open the section, which
may not be stored in sessionStorage, as DT can recover
from localStorage.
Bug: T338920
Change-Id: I695e2d423b5159ef4cdcefc0f4d4d0a05f46879b
PHP logging code is not moved.
* Use the new mw.track() handlers from WikimediaEvents
* Ensure that 'integration' and 'editor_interface' are set on init
events, since they're not hard-coded in the handler any more
* Remove the setting of 'editingStatsId' tracking parameter,
now happens in WikimediaEvents (by way of VE ArticleTargetSaver)
* Remove code connecting ve.track to mw.track, now happens in VE
This must be merged together with WikimediaEvents change
Iace4d53a972396ca5b8713000570cc47c9986034 (but we can't use
Depends-On, because CI requires code here to be removed first).
Bug: T332438
Change-Id: I0ef0a96aafdf89a4ebe32131a85b18c25744bb2c
To avoid affecting existing preload forms, the new topic tool is only
used when the 'dtpreload' query parameter is also set.
Bug: T269310
Change-Id: I4ee024cc4760542790319f302f42b1b2389ac897
Previously we only did it when re-initializing after saving a reply
using our tools, but it could happen for a different reason, such as a
NWE edit.
Bug: T317035
Change-Id: Ia8152fc83f74689802f8dbbc20607c9026a2a5ab
Instead of doing them right after page load, only do them on
hover/touch/focus, when we can expect that the user is about to
click/tap/activate a reply link, but which lets us start the work a
fraction of a second earlier.
Bug: T325598
Change-Id: Ida4cb70d8e9ab423ad2dabca7258f92e9fca3157
This should avoid hitting the API if the DT JS is loaded off of talk
pages. At worst, if this is overly restrictive, later calls should still
load it when someone actually interacts with a reply widget.
Bug: T325477
Change-Id: If898dd4a21f1d2620c5a1e79908647070c441854
Can be merged once I85ee8e6ed6 has been deployed long enough
for all the caches to have been purged.
Change-Id: Ic9773c2e45a4aa796cb6bca52e58d7db1016a977
The subtitle prop and some others were missing from the action=parse
request. Use the same props as the VE edit API.
Change-Id: I8e9cc735d3ee50dfe0fbe0349713d88654ad9fd1
We cleared the highlight outside the setTimeout(), then set a new one
inside the setTimeout(). If this method was called twice quickly, two
highlights would be created, and the first one of them would become
impossible to clear.
Move the setTimeout() outside of the method to avoid this.
Bug: T311021
Change-Id: Ic8b2cf2a782a429c4ea073871efd215f4b300ed8
It's needed for the fix for T303396 to work correctly (in the case
where there's exactly 1 thread item on the page), and for the
highlight improvements in Iadbf83e02801fd9bd6336c84015994ee2819ce51.
Change-Id: I2b2f5535ebbf792910133622a271ac1491c74de6
Rather than making our own ThreadItem objects from scratch,
reuse those used by the rest of the code.
Change-Id: I67f5ea3ad26baffe51b66d0c75467ac00185dd0a
We switched to our memory-wrapped store everywhere outside the
VE surface, but not in the VE surface itself.
Change the way we construct MemoryStorage objects so that they can
be constructed from a specific mw.SafeStorage instance.
Ensure MemoryStorage's cache is populated with initial storage object
data, and that the cache is copied over when we create derivative
objectes.
Bug: T310438
Change-Id: I652428f114dc5169195887cb8ca719ae196bb76f
If the user can't edit, tell them why, instead of trying to
advise them to use the edit button that they cannot see.
Bug: T303110
Change-Id: Ibc41732a55443331e432987e630976610901c599