It's slow, especially on large pages, and it's triggered
very infrequently these days, and only for known bugs.
In the future we should replace this with a debugging
interface that displays the DOM diff between the original
DOM and the round-tripped DOM, as opposed to the boolean
interface we have now.
By extension, this also means the visualeditor-needcheck
tag won't be applied to new edits any more, although
its registration and messages are kept around because
edits with this tag still exist in page histories.
Bug: T87161
Change-Id: I909153492a5786b4b69fccd42ce3c1d4bdb3a059
Originally added in 5036099906.
* Account for bug T89513 for 'tempdisable' (was done for 'enable' in 9cba9910c6).
* MediaWiki core now loads user defaults in a separate module not
subject to page caching, making our workaround obsolete.
Keeping defaultthumbsize as that is intentionally ignoring the user's
preferences.
Change-Id: I07a7aa8e08c728ddeba67f36a98e989c220dcb50
* Ensure that the toolbar remains inside the target so that
target triggers still work
* To keep the page title beneath the toolbar, move it inside
the target on setup, and restore it on teardown
* Have teardownToolBar/DebugBar return promises so we know
when teardown is completely finished.
Change-Id: If2a9ce9a653aed51d21c8e8dd7795f2533d54f70
* Use .ve-activated for elements changed in activate()
- hideReadOnlyContent()
- mutePageContent()
- mutePageTitle
* Use .ve-active for elements changed in onSurfaceReady()
- hidePageContent()
* Set 've-activated' class from activate() instead of transformPage()
to consolidate reflows and minimise DOM interaction. It's still
in the same (synchronous) execution path, but a few statements
earlier now.
* Remove obsolete #toc wrapper. This <div> (with data property
to distinguish it from potentially foreign parents in the future)
was there to aid slideDown/slideUp animations, because those
don't work well on table elements. See eba7d58dd1.
* Remove obsolete setTimeout in restorePageTitle().
The removal of .ve-init-mw-viewPageTarget-pageTitle was delayed
by one second (introduced in Ibc3fa2fb7 / 4cc88b9850). This
was to account for a jQuery animation we no longer use.
* Remove unused '.ve-init-mw-viewPageTarget-transform-muted'
* Remove unused '.ve-init-mw-viewPageTarget-transform'
* Remove unused '.ve-init-mw-viewPageTarget-pageTitle'
The resulting stylesheet exposes that we're not consistent in
whether elements hide immediately (ve-activated) or once the
surface is ready (ve-active). This is intentionally kept as-is
within this commit.
Of the different elements that had their opacity changed, only
firstHeading was being animated. This animation was removed.
Bug: T88590
Bug: T87160
Change-Id: I87033456f715d99a88425e38e8ac5171144f4ec8
Its white overlay is pretty good at obscuring them, and the notices popup
would close when the dialog is closed, making it very easy to miss them.
Also fixed indentation.
Bug: T86987
Change-Id: I9f93c4169de98ef77a1eb33fd31a0ec524b6d2b7
MobileViewTarget.
Due to this being missed, pageName was getting set to a jQuery object,
which eventually got passed as a data value in a $.ajax call, causing
jQuery to emit a TypeError: Illegal invocation.
I guess this needs a MobileFrontend commit as well. Don't think it fixes
all the issues with loading VE mobile though.
Bug: T78710
Change-Id: I431a902563f608a7a33028cd60112f39c57000a4
Local changes:
* Call bindHandlers()/unbindHandlers() in activate/deactivate
* Extend onDocumentKeyDown rather than overwriting it
Change-Id: I0739e71781c5140c54512ab421bdcb6d1df5fbbe
Follows-up b0e8900, 447e8de, d3f26e65.
Contrary to binding a reference, this-overiddes for inline
functions gets messy and fragile. There's also a minor
performance overhead that can be avoided. No separation of
concerns, eiter, as the object is held by the closure.
Also:
* Remove left-over instances of @method.
* Remove redundant '0' argument to setTimeout.
* Use null instead of $ for apply() on static methods like $.when.
* Use .empty().append() instead of .html(). Does the same but
without additional overhead and without confusion association
with "html" which isn't used (it doesn't serialise and re-parse
or clone, it just appends when given one or more nodes).
Change-Id: I797a3667c67d52568150be9be5d043d149f22077
Various VE elements use escape to perform tasks. Particularly
difficult are OOUI dialogs which listen to the document and thus
fire after this target's listener, so defer and check if the
event was previously stopped.
Bug: T78201
Change-Id: Ie335f199766923833588202626c3af8e4cbcb9b5
New changes:
9929b6d [BREAKING CHANGE] Make ve.init.target an OO.ui.Element
Local changes:
* Fix target constructors now they generate this.$element
Change-Id: Ia6bf604c67305834a3f73863a10336cfbb83fa77
New changes:
776e801 Delimit text nodes in debug observations
72643bc Remove debug bar hiding now it is handled by the surface
cf1e167 [BREAKING CHANGE] Multiple surface support and demo
Local changes:
Account for detachable toolbars in core being setup in a different order.
Change-Id: I29156948711d55ba5f6dd4f6c35ca0e4cca32373
This doesn't quite tell us about the user's first interaction with
VE (if they open a dialog, for instance, it could be minutes before
that results in a transaction), but it's a good start.
Bug: T76524
Change-Id: I6bac987332802d7363ed65a471b2b1ece67086d8
New changes:
fc4af20 Fix filibuster expansion bug
3feadb2 [BREAKING CHANGE] Refactor for multiple surfaces
Local changes:
* Use target.getSurface now that targets can have multiple surfaces
* Remove debug bar code now surfaces manage their own
* Remove import rules code now implemented in base target
Change-Id: I18d6f9f2f36431959d31347b4c1952a1aca1350e
It's good that we're not trying to close the save dialog
if it's not open, but we still need to release our reference
to it in that case, otherwise trying to open the save dialog
in a new incarnation of the editor will fail.
If you opened VE, opened the save dialog, closed it,
went back to read mode, opened VE again, and tried to open the
save dialog again, it would fail because it tried to open
the cached reference to the previous editor's save dialog.
Bonus: prevent JS errors in this case by only attaching an
onClose handler if the dialog actually opened successfully.
If opening the dialog failed, the callback parameter isn't
a promise but an OO.ui.Error, and calling .always() causes
a JS error.
Change-Id: I62d6d3e7cd3df2c29a0c99e2e23bf1aac5187a12
New changes:
5eb7294 Find and replace
123a6ad Find and replace tool
557f70f Go backwards through find and replace results on shift enter
4a4ed81 Allow language widget to filter on available languages
Local changes to adjust.
Change-Id: I15e14d6d3c7ee60e465baf3a4df7572851cbca3e
Both onDocumentKeyDown and onViewTabClick would check
this.activating and invoke deactivate() differently depending
on its value. That's ugly, so incorporate the "don't show a dialog
if deactivating during activation" logic into deactivate() itself.
Rename the override parameter to noDialog, and fix the broken
logic around it (it overrode too much).
Also move setting this.activating = false; out of these event
handlers into cancel(), where it clearly belongs because
activatingDeferred is being rejected there.
Change-Id: I6c040c74d36f829128a175f00d4e712dd19d31a7
Or at least open the confirmation dialog about it.
Relies on I0047bd9d to not break stuff on the second try.
Bug: T52868
Change-Id: Id178a2a0aad2f4bf5f589d66efde61aaa6fae498
Method was moved to parent, but not deleted from child. Also move
sanityCheckPromise to parent where it is used.
Change-Id: Ie2b00330d796cd089fd4bc84d9332c316500633f
Uses the generic sequence detection now available in core instead
of a custom hack that had to been manually bound and unbound to
every surface and surface widget.
As the sequence detection looks at just-typed characters the behaviour
has reverted to showing a auto-hide message. This resolves an issue
with the previous system whereby typing in the same paragraph as existing
wikitext patterns triggered the warning.
Depends on I6a4d71d in core.
Bug: T53751
Change-Id: I7d914b1b60a1cf8c79a724e5f634e1e666c9562d
Local changes:
* Rename paste rules to import rules (also used by drag and drop)
New changes:
f5d83f8 Remove data-parsoid removal hack
99f938f Create 'preserveGenerated' mode for cloneElements and use in copy
938b44d [BREAKING CHANGE] Rename paste rules to import rules
c51288c ve.ce.Surface: Move insert HTML path to DM
10ce4cf Provide a FileDropHandler for HTML files
701bb9c Provide a FileDropHandler for CSV and TSV files
ca6b444 build: Update update-oojs.sh and update-oojs-ui.sh scripts
Change-Id: I5cfa15ab3efd03e2c64c2f9f725cb3098f53b32a
Also remove toolbar definitions as they can now be derived from
command availability.
Depends on If32d514a in core.
Change-Id: I2313f3cc2531686b27f96dc1110b28bb4b295f89
Otherwise the closure promise will be rejected as it was already closed with
different data, if you ever opened and closed the save dialog before pressing
the 'Read' button. This means the code in the $.when will never be run, and
the surface never destroyed.
Bug: T75589
Change-Id: I3ffdd1c82506bcd2accc0f3fa113c0950a31918e
It would tell you you were logged out when you were actually
logged in, and when I looked into it, I found lots of broken
things, including lots of confusion between the current
anon-ness and username and the new anon-ness and username.
ve.init.mw.Target:
* Check the new isAnon value, not the old one
* Pass the username to the event, rather than just anon-ness
ve.init.mw.ViewPageTarget:
* Use the passed username (new username) rather than the
username from mw.config (which is updated, but confusing)
Change-Id: Icf406d49100d81e87c677fd6b57ff93cc29f601f
Move ve.track() subscriber to its own file, and have it
route mwtiming.* events (for TimingData) and mwedit.* events
(for Edit schema) differently. Most of the data population
lives in the subscriber, so actual ve.track() calls are
pretty lightweight.
Existing ve.track() calls with timing data were kept with
their names intact for backwards compatibility, but
we may eventually want to throw them out and start from scratch.
ve.init.mw.ViewPageTarget.init.js:
* Remove old track subscriber
* Track init and ready events
* Remove old ve.track( 'Edit', ... ) crap that didn't work
ve.init.mw.ViewPageTarget.js:
* Fire the saveWorkflowBegin event before the save dialog
loads rather than after
* Remove unnecessary this.events.trackSaveError() calls:
TargetEvents already listens to these events itself
* Remove badtoken handler because all it was was an
unnecessary trackSaveError() call
* Add abort tracking
** Pass trackMechanism through deactivate() and cancel()
ve.init.mw.Target.js:
* Add static.integrationType to populate the 'integration'
field in the schema
ve.init.mw.TargetEvents.js:
* Simplify onSaveError* methods away into connect bindings
* Map track topics to mwtiming.* so they can be routed separately
* Track save-related mwedit.* events
Depends on I978eda96c in WikimediaEvents
Change-Id: Iae677d9b15c71d2b18e795bd5179d11876c06abd
Make sure it always gets torn down on deactivate, not
just on save. Otherwise we end up with multiple copies of it.
Change-Id: I7b95c316641fc48ce7087a0042ec6174fe03180b
If you clicked "Read" while the editor was loading
(but only while the "Edit" tab was already active, not before)
then you could get in a situation where surfaceReady fired
on an already-aborted target, which caused JS errors.
It seems like we should clean more things up in this
case, but I don't know what they are. In any case,
we should not try to set things up on a non-activating
target when surfaceReady fires.
Change-Id: Id57bd63ff288156725e472e7d89009022090253a
Follows-up Ica33de675, If505a46f54.
* The setting of 'uri' looked like a redundant local alias before
passing on to pushState, but is actually important on itself.
* Remove binding for hideLoading. It's a detachable method on
a singleton, not an instance method.
Change-Id: Ic3536caf3f42ee893124312fd5981b67336bd480
When you clicked the Back button in the browser, the URL
in the address bar would change (removing veaction=edit),
but we would not go back to read mode. This was broken
by 5c0c11753 almost a month ago but apparently no one noticed.
This is because 5c0c11753 moved the pushState() calls to
be earlier (in init init), making the replaceState() call
in the ViewPageTarget constructor (which is there
specifically for this bug) run too late in those cases.
The simplest way to fix this is to duplicate these replaceState()
calls before the pushState() calls in init init.
I feel a bit bad about copying code, but not very bad
because the code I'm copying already has a FIXME comment
about how there should be a better way :P
Change-Id: I6627a5d1d9377ae815bc58bceeb059ce9f4f19ab
Just like DOM interfaces such as document and location. And JS
constructors like Object.prototype, and libs like jQuery.
No need for the window host object.
Change-Id: Ie39aaea2ca17bdec5fb3afe32a4e6c9f751bd0c6
The location object is a global, just like document.
Using it via 'window' needlessly adds complexity and, for example,
makes it harder to catch typos in static analysis.
Standardise on location.href in place of the many different
variants for accessing and assinging the full url:
location =
location.href =
location.assign() =
And each with 'window', 'document' and without host object.
Change-Id: If88515bd88fc5b93ebacd4ec41fce02fec540f18
mw.msg can return things with <br />, which we want to be interpreted as HTML
rather than just escaped as text.
Bug: 73571
Change-Id: I7861432d9361e01f9def0578c342e60715c3d764
ApiEditPage can give us 'nochange' instead of the
'oldrevid'/'newrevid'/'newtimestamp' keys if we gave it a null edit.
Bug: 73463
Change-Id: Ic22597dfed11de3823471673404090a9bce12928
After 5c0c117, clicking the VE edit tab on /wiki/Foo?oldid=123
sent you to /wiki/Foo?veaction=edit , dropping the oldid parameter
and editing the current version rather than the old version.
Fix this by only recomputing veEditUri from scratch when necessary,
and reusing the current URI when possible.
Change-Id: Iee9a745990f1a2bad40f46b8cdaaa727bb7fead8
We were attaching its removal to the wrong promise in 2 of the 3
places where it was being called.
Also this file is horrible and should be refactored. A lot.
Change-Id: If74b1629266f22e2d110305b139bef4a8e69b13b
The container is zero-height and zero-width, so jQuery doesn't
consider it :visible, and yet it still takes up visual space.
Bug: 72693
Change-Id: I3bed5394a2a64a9f7f0a331f850aa412b5b11b7d
Moved the spinner code from ViewPageTarget to ViewPageTarget.init to make it appear immediately on clicking edit.
Bonus: also fixes the URL to add the parameter vesection when clicking a section edit link.
Bug: 65453
Change-Id: Ica33de675203cc0f0594b8362731c4e98a644313
Just hide them when opening the editor and show again afterwards. Will
need Parsoid for proper support.
Corresponding patch in core: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4.
Bug: 23796
Change-Id: I3ce5e7869be50dcd189ca24e2b3d7ebc62de4fc4
New changes:
8d5ec7a [BREAKING CHANGE] Rename ve.Document.getNodeFromOffset to getBranchNodeFromOffset
Local changes:
* Update calls for rename of getNodeFromOffset to getBranchNodeFromOffset
Change-Id: Ibc69f5a5deeed5698368bb19b30f14497c579e90
Instead of doing a blocking overlay, we're simply keeping the dialog open,
which is necessary for the pending status of the action buttons anyway.
Requires Ib2c8f336 in OOUI
Bug: 65012
Change-Id: I65b5de4a1666a81b157a71f6fec490007689eb44
That function needs to return the result immediately, not wait for module loading (via mw.notify).
This was breaking us being able to keep track of what wikitextWarning object was in use (but only
the first time we used the module), and therefore fail to close the warning when the wikitext
disappeared.
Bug: 70168
Change-Id: I0f1427423a5fe82ec8e70e2f0462a3044ca7ace8
