jQuery's implementation does some sort of traversal, so on large pages
it took 300-400ms just to focus the document node.
Change-Id: I0de95d8800a1aedeb19b27d204dfd8fd08cec533
In aaa5ad2 we introduced a feature test. However though we do require
ES5, we don't (yet) use strict mode. It is an easy and solid one to
feature test, but it the unfortunate reality is that IE9 does not fully
support ES5. Strict mode is among the features it didn't (correctly)
implement. As a result commit aaa5ad2 locked out IE9 completely.
Replacing it with a more explicit (and harder to maintain) test that
does pass in IE9. We now need to be very careful about using ES5
features in our code. It has to be in this list here to avoid breaking
in a browser that doesn't support it.
Change-Id: I77b623e15a0791bfaa2cd835e43107cefb3c25f5
This change adds 'page-edit-impression', 'page-save-(attempt/success)',
and '(section-)edit-link-click' events to the standard (non-VE) editor
interface, mirroring the events we added to VE. This makes the event data
usable for split-test analysis.
Change-Id: I51c441d61daa18d58ca7f62a9e5f07902a099050
It's been replaced with 'mw-editsection' and all cached renders on
Wikimedia wikis have expired by now. All backwards-compatibility
occurences have been removed from MediaWiki core already.
Change-Id: Id3731222445b588de8aec0e86892879ac4472636
By default, EventLogging uses INT columns for integers, which pageViewSessionId
overflows. I changed it to a STRING type in the schema and am now generating it
using 'mw.user.generateRandomSessionId()'. I also introduced a 'userId'
property, per bug 49585.
Bug: 49585
Bug: 49586
Change-Id: Iddb9eb9c64b55b25445ddf9e474d312b685978a6
This change adds a '$wgVisualEditorEnableEventLogging' configuration
variable, accessible client-side as
'wgVisualEditorConfig.enableEventLogging'.
When true, the 'schema.Edit' ResourceLoader module will be loaded on the
page, and calls to ViewPageTarget.logEvent will forward to
mw.eventLog#logEvent.
When false, the module is not loaded, and ViewPageTarget.logEvent is a
no-op.
The change also adds a few calls to ViewPageTarget.logEvent to log certain
editor actions, documented in https://meta.wikimedia.org/wiki/Schema:Edit.
Change-Id: Iccd171d7cde15b0302d1b4c292bcbcc2a4b337ef
Objectives:
* Remove the whole toolbar subset thing, it's up to the creator of the
subsurface to know what is and is now allowed, and the commands were
still passing through unfiltered
* Correctly separate initialization from opening - fix issue where opening
the reference dialog multiple times will keep adding more and more
controls
Changes:
ve.init.Target.js
* Remove getToolbarSubset method
ve.ui.MWReferenceDialog.js
* Add toolbar tools and surface commands configs to reference dialog,
including the things that are safe to use in references
* Move creation of field sets and reused controls to initialize method
to prevent re-creation each time the dialog is opened
* Move static initialization stuff to the top near the other static stuff
Change-Id: I1c8577d17c506bac76e61b2b036655c59ef5a218
Objective:
* Allow opening reference dialog with arbitrary selection
* Auto-insert reference when selection is not a reference node
Changes:
ve.init.mw.ViewPageTarget.js
* Added reference button to toolbar
ve.init.Target.js
* Add getToolbarSubset so we can exclude the reference button from
the toolbar in the reference dialog (nested references are not
allowed).
ve.ui.MWReferenceDialog.js
* Stop storing referenceNode (not needed)
* Only store internalItem on open if there's a focused node that's a
reference
* Use wrapper paragraph when creating a new reference
* Create new reference on dialog close if required
ve.dm.InternalList.js
* Major rewrite to support key less references.
* Add new method for creating a transaction to insert a new iternal
item. Also returns the index of the new item to be passed to the
reference node.
Change-Id: I839ae165c299248484ce93d4ab087318a95fbb94
Introduction of fake selection for single focused nodes. This
change specifically makes the selection much nicer in appearance
for Chrome users selecting floated FocusableNodes (block images)
for example.
Added ve-ce-surface-highlights DOM element to contain styled
highlight elements.
Made adjustments to getSelectionRect to return fake selection
bounds if necessary.
Replaced old uses of showSelection with model.change().
Change-Id: I96e66567cdce6455ef3eb77568e72f23140448ff
Removed the "report" slide from the mw.ViewPageTarget save
dialog and everything that becomes obsolete as a result of it:
* JS saveDialogReviewWrongButton, which pointed to the report
slide (was already hidden as of I90de95f6337ee).
* JS ve.init.mw.Target#reportProblem.
* JS ve.init.mw.ViewPageTarget#diffHtml.
* JS ve.dm.ElementLinearData#getUsedStoreValues.
* PHP mw.config wgVisualEditorConfig.reportProblemURL.
* PHP $wgVisualEditorParsoidProblemReportURL.
* I18N visualeditor-savedialog-title-report.
* I18N visualeditor-savedialog-label-review-wrong
Change-Id: I8a5e0ab2060d7c14086bba413d4c7d73b29c9b97
Summary:
Instead of having a button "Review and save" that opens with a
diff and leads the user to the "Report a bug" and "Save page"
slides respectively, make it more like the default EditPage.
There is now a "Save page" button that opens with the save
form with a button to "Review changes" (diff) or "Save page".
The "Report a bug" slide has been unlinked from the UI and is
no longer accessible for now.
As a result of the UI no longer requesting a diff upfront this
also means we will no longer detect "nochanges" event (when it
turns out the submittted revision matches the latest version).
This is unfortunate as it was a nice feature to detect it
before the user spends time writing the edit summary) but it
is the same as how the default EditPage works.
Changes:
Improved interface messages.
Adapted "nochanges" caption to the new context (it is no
longer shown when clicking "Save page", it is now shown as a
result of clicking "Show changes").
Now that the "save" slide is accessible from multiple paths
it is needed to keep track of slide changes in a history
array. Previously the slide tree was 1 level deep with
everything descending from "review". Now it starts at "save"
and can go in multiple directions including a loop from
save>review>save. We also need to toggle the "Prev" button
based on history instead of based on whether or not we are
on the "first" slide.
Hid the "saveDialogReviewWrongButton" from the review slide.
We're approaching wider launches and this will not scale to
a wider audience.
Bug: 49258
Change-Id: I90de95f6337eeddd794b75d56543d8d152421a6f
Objective:
* Allow inserting images from local wiki and commons
Changes:
ve.init.mw.ViewPageTarget.js
* Add media insert button to toolbar
ve.init.mw.Platform.js
* Add getMediaSources method - defaults to local wiki and commons
ve.ui.MWMediaInsertDialog.js
* New dialog for inserting media
* Uses a media select widget and inserts block images
ve.ui.Dialog.css
* Added styling for media select widget in media insert dialog
ve.ui.Widget.css
* Added styles for media select widget and media select item widget
ve.ui.MWMediaInsertButtonTool.js
* New tool for inserting media
ve.ui.MediaSelectItemWidget.js
* New item widget for media select widgets
ve.ui.MediaSelectWidget.js
* New widget for searching for and selecting media items
ve.ui.TextInputWidget.js
* Added isPending method
VisualEditor.i18n.php
* New messages for media insert dialog
VisualEditor.php
* Added links to new files and messages
PhantomJS--
Change-Id: Ia803ff3ef518782ce76802d2dab7559686a1bb0a
This is mainly used for testing blacklisted browsers, so we just need
one parameter ('vewhitelist') which sets whitelist to true and
blacklist to false.
Change-Id: I38771ba7a49657d67c4d94ace1f30b5e41904df6
Browser history state:
* Listen for popstate, if veaction is different, act on it
(by calling activate or deactivate).
* When switching to edit mode, push veaction=edit.
When switching to view mode, push non-veaction.
Except if the switch was made by the popstate listener in
which case we don't want to push again.
Clean up:
* Use document.location.href instead of odd location.toString
Don't pass it to mw.Uri from the original one since it
takes the current url by default.
Bug: 43844
Change-Id: I5c345c1526852a84b04436955845bf1b56d94402
Merge methods:
* transformPage: transformSkinTabs + hideSiteNotice
* restorePage: restoreSkinTabs + restoreSiteNotice
Callers now consistently do both (e.g. #tearDownSurface only
called #restoreSkinTabs). This is also in preparation for
bug 43844.
Removed call from #tearDownSurface as that method is only
called from #deactivate which already calls #restorePage.
Clean up support check:
* Rename supportsStrictMode to supportsES5. Though the feature
test asserts strict mode, we use it to check support for
ES5. VisualEditor doesn't particularily care about strict
mode itself.
* Reverse support if-statemement to return early instead of
wrapping everything that follows. This makes it easier to
see that we intent to abort if the current environment is
known to be problematic. Also easier for code later on
by not accidentally falling outside this block
* Follows-up aaa5ad254b.
Change-Id: Ia4b949d9c066a3f7b07217aa3d51de9908734e85
The previous fix didn't really work, because the notices are expected to
be an array elsewhere too. Better to just convert it to an array on the
spot. getObjectValues works with any kind of object (including an array)
so it's safe to use with either data type.
Change-Id: I03237b8624a0b980e5f70d54d55c662ffa460373
We now have three stages:
1. Browser feature tests. Dies silently if any fail.
2. Browser blacklist. Dies silently if match found.
3. Browser whitelist. Shows warning if no match found.
Previously we were treating the remotely generated
edit notices as if they were in an object when
in fact they were in an array - the code has been
fixed to reflect that fact.
As locally generated notices will typically require
parsed messages, we've also moved the notice rendering
to after onReady is fired.
Updated jquery.client to latest master from MediaWiki core
(needed for proper detection of Iceweasel, Android and Safari)
Bug: 38128
Change-Id: Idc5f4a23a2709264d869a91d00873c4e187bc470
Prologue:
Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't
see you there! In a world where iframes are outlaws, and symbols like
document and window are global, there were more than a few assumptions
about which document or window was being used. But fear not - for this
commit (probably) tracks them all down, leaving a trail of
iframe-compatible awesomeness in its wake. With the great ve.ui.Surface
now able to be used inside of iframes, let the reference editing
commence. But there, lurking in the darkness is a DM issue so fierce it
may take Roan and/or Ed up to 3 whole hours to sort it out.
Note to Roan and/or Ed:
Editing references seems to work fine, but when saving the page there
are "no changes" which is a reasonable indication to the contrary.
Objectives:
* Make it possible to have multiple surfaces be instantiated, get along
nicely, and be embedded inside of iframes if needed.
* Make reference content editable within a dialog
Approach:
* Move what's left of ve.Editor to ve.ui.Surface and essentially
obliterate all use of it
* Make even more stuff inherit from ve.Element (long live this.$$)
* Use the correct document or window anywhere it was being assumed to be
the top level one
* Resolve stacking order issues by removing the excessive use of z-index
and introducing global and local overlay elements for each editor
* Add a surface to the reference dialog, load up the reference contents
and save them back on apply
* Actually destroy what we create in ce and ui surfaces
* Add recursive frame offset calculation method to ve.Element
* Moved ve.ce.Surface's getSelectionRect method to the prototype
Bonus:
* Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it
was separate in the first place, but I'm likely the one to blame)
* Fix blatant lies in documentation
* Whitespace cleanup here and there
* Get rid of ve.ui.Window overlays - not used or needed
Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
If the commit message is empty we show a warning, and if the warning
is already visible we allow the user to proceed.
Bug: 47752
Change-Id: Idba707abaea8b08a94f7fa4d5bc5b1e35261a572
