This is the outer range of the parent of the node, if known. We'll need
this for change marking: when resizing a text node, for instance, we
need to mark its containing parent. This way we get the containing
parent's element's offset for free (selectNodes already tracks it in
currentFrame) rather than having to compute it with another traversal.
Change-Id: Ia335d8080ea9d414ab9f89b943e2ea0cd11d7df3
Some tests were using the wrong node in the expected data, but because
only the summaries were compared, this would succeeed as long as the
type and length were equal (and paragraphs of length 1 are quite common
in our test data). Fixed equalNodeSelection() to compare each node by
reference as well as comparing the summaries. If one of the equality
tests fails, the summaries will still be displayed as expected/actual
data (even though they might be equal), and the message will have
"(reference equality for selection[3].node)" appended to it.
This change broke the tests because a few test cases had bad data, fixed
those in this commit as well.
Change-Id: Iab420cf29d47f7368c8a9ce79f6309efae75685c
For <p>1<br/>2</p>, selectNodes([2,2]) correctly returned the end of the
first text node, but selectNodes([4,4]) returned index 2 in the
paragraph (i.e. between the break node and the second text node). The
correct behavior is to return the start of the second text node, i.e.
the mirror image of the behavior for [2,2].
Fixed this by applying the startBetween/endBetween logic only if the
relevant adjacent node is wrapped (or if it's missing). In the code,
this is expressed as !(adjacent node present && adjacent node wrapped).
Change-Id: Ie3b7fdf1de38ee253a798a7a73bc89734f4ca4fa
The HTML "1<br/>2" was being converted to a linmod that looked like
"<p>1</p><br></br><p>2</p>". This commit fixes the wrapping logic such
that the result is "<p>1<br></br>2</p>" instead. In general, inline
nodes (content nodes) should not interrupt the wrapping, but block nodes
should.
This creates a problem for alien nodes: normally, we determine whether an
alien node is a block alien or an inline alien based on context, but if
we're in wrapping mode we're unsure of the context. We can't tell the
difference between "1<tt>Foo</tt>2" (should be wrapped as one, because
tt is inline) and "1<figure></figure>2" (1 and 2 should be wrapped
separately, because figure is block) using context alone, so in these
cases (and ONLY in these cases) we look up whether the HTML tag in
question is an inline tag or a block tag and use that to decide.
Change-Id: I75e7f3da387dd401d9b93e09a21751951eccbb83
* Added comments to classes and methods
* Quieted a jshint warning
* Broke some long lines
* Replaced instances of "var\t" with "var "
Change-Id: I1d617ed9e5180f1a3dff42078fb5debb5d718407
Firefox triggers a keypress event for backspace. We handle backspace in keydown, so this keypress event should be ignored.
Change-Id: I6a481dbd5df0cf4558a5f1975717ca809250ccda
* CenterNode missing in ResourceLoader registry
* UI classes and rangy not in static test/index.html
* Transaction and TransactionProcessor listed twice
Added a maintenance script that generates the <script> and <link> tags for all
files in the same order everywhere.
Change-Id: I5d22d33769b4e356e8065d295505f6f9a8b0bea8
If you select some text and start typing, we will now remove the content in the range and new content will be annotated with the annotations from the first character in the deleted range. This is similar to other editors.
Change-Id: I46ced52665ab10f9b724dbb225df5687c18a4c3a
Exception was caused by passing -1 to getAnnotationsFromOffset(). So
check for -1 before passing it in; getNearestContentOffset() can
legitimately return -1 if there are no content offsets in the document,
which occurs when the document is empty.
I was originally going to change getNearestContentOffset(start - 1, -1)
to getRelativeContentOffset(start, -1), but Inez correctly pointed out
that that would have unwanted results when near an inline node.
Change-Id: Ife4b497b1c5fd04d411bb25cea99e6ea2abf146f
This was reproducible by blanking the entire document (Ctrl+A Delete),
then undoing that (Ctrl+Z). AFAIK that's the only way to trigger an
insertion on a document that is completely empty.
Change-Id: I22252d5972a413dff614880a90c4c6b22e79672d
Also changed from using "type" to "name" to make it less specific and added a test to make sure it's working.
Change-Id: I150a7ab1a57b3df85b459dbc411c2eaefe08b5bb
The annotation-related code in the converter is greatly simplified
because the API itself takes care of almost everything already.
Change-Id: Ib48f52bad6b650a05dc4e7ef82db4158c19b3cf5
This changes ve.dm.LinkAnnotation to be a generic annotation for <a>
tags, and adds ve.dm.MWInternalLinkAnnotation and
ve.dm.MWExternalLinkAnnotation as MW-specific subclasses. This nicely
splits out the MW-specific parts in LinkAnnotation, and ideally we'd
also move these files somewhere else to reflect their MW-specificity,
but I haven't gotten to that yet.
Similarly, ve.dm.TextStyleAnnotation is now a generic base class for
simple tag-only-no-metadata annotations, and it has 11 subclasses, one
for each tag we support. This is quite a bit more verbose than the
previous code, but I think it's cleaner and more flexible. I considered
writing a function that would generate a TextStyleAnnotation subclass,
then calling that 11 times, but that's not possible if we want to keep
named functions for the constructors.
Change-Id: Ifba10153eef40280e44025dd72d4e9d9f33b0632
Fleshes out ve.dm.Annotation to a class. Annotations in the linear model
will be instances of a subclass of ve.dm.Annotation. Annotations are
defined by subclassing ve.dm.Annotation and registering this subclass
with ve.dm.AnnotationFactory.
ve.dm.AnnotationFactory keeps track of which annotation classes are known,
and has code to match an HTML element to an annotation class, for use in
the converter.
Change-Id: I68802bdb8736ced1f9e04ee49c623944b448141c
