That's where they belong IMO, since ViewPageTarget is the one that
has .activate() and .deactivate(), and mw.Target doesn't retain any
state (apart from some caching things).
Change-Id: Ia6cf5bac9054163d54ab492d691d8ce9d6a3bb90
* changes:
Split apart onSaveError logic for other mw targets
mw.ViewPageTarget: Remove unused onTokenError handler covered in onSaveError
Create base MobileView config and target refactor
Changes include:
* Target mobile for ve dependencies
* Create mobile view constructor
** Some tools like dialogs are excluded for now
* Refactor mw.target to permit code reuse
** Split out pageTarget view functionality from core init methods
Change-Id: I786b63ab57518fc6af7761501259ed66592f70e3
It's possible for the user to put the cursor back from the inspector
in the surface without triggering a selection change, if the selection
was collapsed and they clicked in exactly the right spot.
In practice, this can happen if the link inspector is open in creation
mode and the user clicks to drop the cursor at the same position where
it was when the inspector was opened.
When this happens, the inspector wouldn't close, because it only closed
in response to selection changes. If the user then typed something,
weird things would happen.
To prevent this state (cursor is in surface but inspector is open) from
occurring, close the inspector and hide the context when the document is
focused. This fixes the link inspector creation mode issue, and it also
causes the link inspector to no longer briefly remain visible after the
user has clicked out of it.
Bug: 56976
Change-Id: Ib70fc13031873009a175e4b049a07694a87ce25d
Add .csslintignore file for the csslint run by Jenkins.
Also updating our Gruntfile for local usage to include demos,
which Jenkins is going to include as well (as it uses an ignore
blacklist instead of whitelist).
Change-Id: I9114cfc54e82f090f0fcf62155ef7c1a9261548d
They contain iframes and those need to not be display: none;
in order to make Firefox happy.
Bug: 57568
Change-Id: I177877bff3c3b18bfc87ee4e6afa7e60fea26ffc
There's no point in hiding the WindowSet if we've already closed the
open window in it. In fact, there's no point in hiding a WindowSet
pretty much ever.
Change-Id: I49a02b5d255b266eb9e0a537cb64082eb0ad5e4b
ve.ui.MWReferenceDialog.prototype.teardown:
* Pass ranges rather than nodes to transaction builders
* Don't do a removal in insertion mode, we know the removal range
will be empty
ve.dm.Transaction.newFromDocumentInsertion:
* Correctly splice the edited internalItem into listData in the case
that newDoc isn't a document slice of doc
* Rename range to spliceItemRange for clarity
* Introduce spliceListNodeRange and set it to either newDoc's
listNodeRange or doc's depending on whether newDoc is a slice of doc
Bug: 57683
Change-Id: Iae7de7701ae86bed89b707038407243d82249e1a
Using display: none; on the inspectors WindowSet causes Firefox to
neglect to load CSS in the inspectors' iframes, which means the frame
never initializes and the inspector never opens.
Bug: 57568
Change-Id: Ia1a0ce78754fa1318a7d439abe1f0e2f86420e7a
Currently we assume getNearestContentOffset will give us something
sane however it can return -1 when there is no nearby content and so
an exception is thrown. In this case we have to create an empty
paragraph to place the cursor in.
Change-Id: Ic6c19da881e47ff6be45cdaa4b71bfcc1c654796
MW extensions are XML not HTML, so we shouldn't build them as XML
to prevent HTML specific rules being applied, such as <source>
always being self closing.
Bug: 54577
Change-Id: I84af4a29cd1c4ae4d1db4f70a4012a8ad0f98bf6
* changes:
Make autonumbered external links inspectable
Always remove the annotation when the remove button is clicked
Add abstract getAnnotation() method to AnnotationInspector
When the target of an autonumbered link is changed to a URL, it's kept
as an autonumbered link and its target is updated. When the target is
changed to a MediaWiki page, the autonumbered link is removed and
replaced with an internal link with the text set to the target.
So for instance, if you inspect [http://www.example.com] and change
its target to "Foo", the result will be [[Foo]].
The core of this commit adds support for inspecting nodes to
ve.ui.LinkInspector. This support should probably move into a
class in between AnnotationInspector and LinkInspector, perhaps
called HybridInspector or something, but I'm deferring that for now.
LinkInspector allows changes to inspected nodes to be reflected either
as attribute changes on the node, or by replacing the node with something
else. MWLinkInspector uses this feature to replace the autonumbered
external link node with an internal link annotation when the target is
set to an external link.
Bug: 53505
Change-Id: Icb404af84c24574438e4de3ef05bbd1993b593f7
When you inspect a link, then close the inspector immediately,
nothing should change. However, AnnotationInspector was comparing
the generated annotation and the existing annotation by hash, and so
would consider an annotation with htmlAttributes different from
one without. This meant that inspecting a Parsoid-generated link
and then closing the inspector would cause a transaction to be
processed that removes the htmlAttributes from the annotation.
I believe a similar issue also existed for annotations with attributes
like origTitle and hrefPrefix, although I didn't reproduce this.
The fix is to have AnnotationInspector compare annotations by the
hash of their comparableObjects, rather than their hashObjects.
Change-Id: I848ffc2b7e7b2c67754a0ece3af105ffafa837ec
Didn't bother to deduplicate blur-focus event pairs that occur when the
focus moves from the documentNode to the pasteTarget or vice versa
(this happens when switching between normal selection and FocusableNode
selection).
Change-Id: If1ccd2fbf11de956b6c2364ae81b9dc20a1bf409
Remove weird check that prevented a removal from happening if the
subclass's getAnnotation() method returned null.
This caused a bug where if you inspected a link, typed an invalid
link target (e.g. '|'), then clicked the remove button (trash can icon),
the inspector would close but the link wouldn't be removed.
However, if you typed something that was a valid link target (or didn't
touch the input at all), the remove button would work as expected.
Change-Id: Ib6efc2a5827b109c6b38185e6d89b7bb29b13a75
It was relied on, and all subclasses had one, but for some reason
it wasn't defined as an abstract method.
Change-Id: I6d48f8ee666bd339be87744840c6edb4abb56dbf
Otherwise the old save dialog will still be around if the user sets up
another surface (e.g. a second edit), but won't be attached to the DOM.
Bug: 57654
Change-Id: I23c10849a212534bdd0600637d8ad4fa3ebc4fb7
