ve.ui.Surface.js
* Make local overlay a child of ve-ui-surface and a sibling to
ve-ce-surface elements.
** This keeps local overlays relative to their surface and eliminates the
need for insane z-indexes.
ve.ui.PopupWidget.js
* PopupWidget boundaries are now relative to ve-ce-surface and no longer
protrude out
ve.ce.Node.css, ve.ui.Window.css
* Removal or replacement of insane z-indexes.
ve.ce.FocusableNode.js, ve.ce.ProtectedNode.js, ve.ce.ResizableNode.js,
ve.ui.Context.js
* Translate offsets from local overlay
ve.init.mw.ViewPageTarget-monobook.css,
ve.init.mw.ViewPageTarget-vector.css
* Skin specific z-indexes for global overlay
ve.init.mw.ViewPageTarget.js
* Applied direction specific mw class to ce.Surface vs ui.Surface to
prevent mw content styles from being applied to ui elements.
ve.ui.Dialog.css
* Adjustments to surface inside of dialog so that relative offsets for
local overlays can be properly calculated.
ve.ui.Surface.css
* Explicitly force .ve-ui-surface to be relative so that it's children can
be relatively positioned.
ve.ui.Widget.css
* Removal of unnecessary font-size properties now that local overlay is
sibling of surface.
ve.js
* Added get relative position helper method to translate position offsets
from target parent
Bug: 50241
Change-Id: Ibadce404a2286bc5dcec48f0d9da89004dbbd867
Resize handle event handling was set up to bind on focus and
unbind on document mouse up. The problem is that focus can be
set programmatically and sometimes more than once. This would
cause the image to be properly resized once, but immediately
resized again to 0x0. Now, before binding events to the resize
handles, all resize handle events are unbound.
Change-Id: I22b7902d303b5ca43e132c121d743d6815980fc6
If a block image is resized and undone, there are lots of problems.
* The block image gets the wrong size. When rolling back the
transaction, height and width are passed as strings.
MWBlockImage tries to set the width to: width + 2. A 300px image
became 3002px.
* Resize handles didn't reposition and resize
* Relocatable drag marker didn't reposition and resize
* Focusable highlights didn't reposition and resize.
Change-Id: I8792b567b77da90ce5a2ad132e306705c5706606
Reference lists would never disconnect, and some transactions would cause them to be "updated" even though they don't have a document anymore.
A way to test this is to insert an image in a document with some references. When you click apply, it crashes.
The solution was to make sure we actually disconnect from the internalList and listNode on teardown.
Change-Id: Ieb0354938b68fe5e7965f61f9ccce07cd6fb1120
Added both bidi-isolation and directionality. Since the directionality
has to come from the user interface (and not the wiki dir itself) I had
to read the $('body') direction. The other option could be adding a
mw.config.get().userLanguageDir that picks up the interface directionality
on top of the wiki directionality.
Bug: 50543
Change-Id: I9a00e9545a46f13750ab0d118b23d05573ee1a2e
Objective:
* Enable navigating search results using keyboard up and down keys
* Bubble up query input enter events
Changes:
ve.ui.SearchWidget.js
* Route query input events to emit
* Add handler for keydown events
* Support navigating through the list of results using vertical arrow keys
Change-Id: Ia2e4b27075a8ab2e29a69294e9f7847e8f5a3f83
Changes:
ve.dm.MetaList.js
* Auto-initialize index to the end of the list (like the docs claim) even when not providing an offset
ve.ui.MWCategoryInputWidget.js
* Cleanup fix for not offering to move the last category to the end
ve.ui.MWCategoryWidget.js
* Allow pressing cancel on the meta dialog after moving a category to the end without crashing
Change-Id: I45059bda022639f7942f1799a42ecf8a4d962df0
Break setUpSurface into a bunch of parts that setTimeout() each other.
This breaks the initialization of the editor as a whole up into the
following phases:
0) Receive AJAX response, parse HTML
1) Build linear model data
2) Build DM tree
3) Build CE tree, CE DOM, create surface
4) Initialize surface, some UI initialization
5) Launch sanity check, remaining setup, unlock editor
This is a bit hacky right now, we'll probably want to refactor later.
ve.dm.InternalList.js:
* Allow construction without a dm.Document
ve.ui.Surface.js:
* Allow construction based on a dm.Document
Change-Id: Ibf48a7e85cd7376c8f6205ed165ff57e71e34c35
Since format dropdown tool is the only tool where we actually lose
focus to the documentNode, we must restore focus so that firefox
and chrome will display a cursor after converting content branches.
Bug: 50338
Change-Id: I4059b2688565570e0efc21078035775b7aed49e1
As part of this, put the 'help' icon next to the beta icon, make the
text not greyed-out (now that it's an actual action) and provide the
link.
On hover, all three items get underlined, which is irritating, however.
Bug: 50476
Change-Id: Id65968072b7134f5864bbd96acf34fd0c23fe17c
Previous when the selection was collapsed and the cursor was in a block
slug we'd get a JS error thrown. This fixes that, though it could do with
a refactor in time.
Bug: 47947
Change-Id: I596ea9bc553f563e3dc7689c518c7d1319ac1dc3
To trigger a save rejection from the api, set:
$wgSpamRegex = '/spam/i';
and making an edit adding the word "spam" to a page.
Class changes:
* Rename message system in the save dialog from "warning" to
"message" as it will now contain both warnings and errors.
(css class, class property, method names, ..)
Localisation:
* Remove ugly hardcoded and wikitext-requiring "'''Warning:'''"
prefix from the warning message, instead have a message for the
word "Warning" and re-use this in #showMessage for each message
of type "warning" (bolding applied in code instead of in i18n).
* Rename visualeditor-savedialog-dirtywarning to
visualeditor-savedialog-warning-dirty and remove from
VisualEditorMessagesModule.php as it no longer requires pre-
processing from the server.
Clean up:
* Re-alphabetise the order of some messages.
* Clean up duplication and redundant logic in mw.Target#onSaveError
and mw.ViewPageTarget#onSaveError.
Bug: 50350
Change-Id: I3daf631fb0d62ba88e05aa50c77c9940d61395a0
Assumption about toolbar height never exceeding 88px is not correct. At
least in Chrome, after setting in advanced configuration font size to
"Large" instead of "Medium", the toolbar's height is 110px and part of it
is transparent. Because it is transparent user can see content behind it
when scrolled down, which makes for a not really good experience.
Change-Id: Ibdc2410cc4ab29bfe774961fc062d172386975d4
We currently change <ref name="foo">Foo</ref> ... <ref name="foo">Foo</ref>
to <ref name="foo">Foo</ref> ... <ref name="foo" /> , because know
that the second ref tag isn't canonical and so we blank it.
Instead, we now preserve the contents of all ref tags that come after
the canonical one.
Change-Id: I45a51a879271890fe46c4184f1029f12d27af678
<table>\n\n</table> round-tripped to <table>\n\n\n\n</table> because
we would store '\n\n' in both the innerPre and innerPost fields.
Fixed by not setting innerPost if the element is empty.
Change-Id: I0393bfaf9793fdebc8fff72c8760113fa69bb2bd
The converter wasn't setting .annotations on meta items created to
represent empty annotations, which meant that HTML like
<i>Foo<b></b></i> would end up as <i>Foo</i><b></b> in the linmod.
Change-Id: I13d7d9820beeee1e8c3673e08051361d6c6ac4cd
If you had <meta /><b>Annotated text</b> in a wrapper paragraph,
the converter would swap them and output the linear model equivalent
of <p wrapper><b>Annotated text</b></p><meta />.
This happened because the meta item was queued, and annotations didn't
trigger metadata queue flushes. The fix is to trigger a metadata queue
flush whenever we're about to write something that isn't itself queued.
Change-Id: I168abc0392fbec5503271d1653ee5c38518f857d
Objective:
* Fix issue where async behavior of addTemplate caused templates to be added in the wrong order
Bonus:
* Get rid of special adders for transclusion parts, just construct objects outside and use addPart
Change-Id: Ibe579f033873446376d72d3bd1b9f92d9f361de5
* 'captcha' property from ConfirmEdit API is already exposed
in ApiEdit and ApiVisualEditor through the 'edit' property
in our response data.
* Add parameters 'captchaid' and 'captchaword' to ApiVisualEditor
and mw.ViewPageTarget#getSaveOptions. ApiVisualEditor will
forward these to ApiEdit which forwards them to FancyCaptcha.
* We display the captcha through a saveDialog warning.
Bug: 50356
Change-Id: Ia7d2102cba89d00ec8508e846061023b330ece4f
We need this for captcha's. They'll be added and displayed as
a warning, and cleared like all others. But they shouldn't be
wrapped in a paragraph and aren't delivered as html text but
as a jQuery object (can't serialise to static html since we'll
have to keep a reference to the TextInputWidget and what not).
Change-Id: I3734fbd3c6f0270094db014bbc76d065a73ab918
This parameter was documented as "HTTP status text" but this
was incorrectly copied from other events. The actual code
never passed anything other than null.
Now documenting it as API response data (if available, else null)
Change-Id: I88c8c525f3ca53fd47de634aec469be372884cfc
