webodf / webodf Goto Github PK

The files loaded via the file dialog are not loaded. The editor just shows 'Loading file.fodt...'

Loading directly via # in the url works.

But somewhere in the runtime extension flat odf files are not properly cared it seems.

Seems there is more work needed with regards to table styles. ODF has table:table-column, but the average browser might have a hard time to correctly guess the semantics of that tag being something similar to and then having to apply any attributes to certain following table:table-cell.

So just mapping the attributes here will fail, Style2CSS.js will have to be a lot smarter here :(

The ODF 1.2 spec § 4.3.2 "Pre-Defined Metadata Elements" lists the metadata elements about which § 4.3.1 "General" says:
"The pre-defined metadata elements have defined semantics. They should be processed by consumers and updated by producers. They can be referenced from within the document using text fields."

Most important here is meta:generator, WebODF should put its name on whatever stuff it creates :) I already have a patch drafted & tested to get the current version into the compiled webodf.js, that part is solved.
dc:date should be also easy, setting the data to (new Date()).toISOString()
Same with meta:editing-duration, could be calculated by taking the timestamp of loading the ODF file and the diff from the point of saving (not really specified what actually is meant with editing-duration).
meta:editing-cycles should be simply +1 to the current value.
dc:creator needs to be set/fetched from somewhere.

Questions: which could should be responsible for which data? And what to do in collab mode, should all that metadata be consistent in all copies?

Most of that code only makes sense with the saved file, as it describes the state of that, and not of the ever-changing runtime model, unless it gets updated on every change:
meta:generator is specific to the client, could be different in theory and hopefully real life. Nothing to really sync between clients.
dc:date, meta:editing-duration, dc:creator are snapshot-bound values, also make no sense to sync that.
meta:editing-cycles is also a bugger. In case of pullbox needs to be communicated between all clients, to make sure it is properly updated on every save by a client. Might for the start just be dropped.

Dropped should be the metadata meta:document-statistic for now, until we have some proper logic implemented to create the statistic.

So seems that besides meta:editing-cycles none of that predefined metadata needs to be synced between clients.

OdfContainer can care for meta:generator, dc:date, meta:editing-duration (last by adding a small var taking the timestamp of loading/creating the container).
dc:creator has to be set or passed in by the code which asks the container to save/fill the zip, same with meta:editing-cycles once supported.

Once we have ops to add/update/remove metadata, those predefined metadata should be possibly explitely filtered out and only the rest which makes sense to sync between clients should be supported.

So far my plan, comments welcome, going to complete implementation in the next days.

If selecting text backwards with the mouse, so setting the focus of the selection before the anchor of the selection, any further modification of this selection (like LMB clicking somewhere else while holding Shift) will behave as if the anchor was instead at the beginning of the selection.

How to reproduce:

1. enter a text "ABCD"
2. select "AB", by pressing the LMB between "B" and "C" and releasing in front of "A"
3. Hold Shift pressed and click the LMB behind "D"

Expected: "CD" is selected

Happening: "ABCD" is selected

The offsets of the clocks at the clients are not normalized, so the editinfo at one client can be confusing.

No idea how to get the offsets between clients, perhaps a diff to the server can be calculated.

How to reproduce:
welcome.odt
remove " too!" from the paragraph with the second annotation
go to start of next paragraph
press "backspace"

How to reproduce:

1. Open Firefox with the welcome.odt example
2. Place the cursor into the line with the annotated text "translate the document".
3. Move the cursor to the line above, e.g. by using the cursor up key or clicking there.

If the cursor is in 3. placed into another paragraph above, the issue does not yet happen, only is triggered once the cursor is afterwards moved somewhere in the upper line of the paragraph before the annotation.

while clicking next to empty paragraphs and headings works for placing the cursor into them, it does not work for list-items.

reproduce:

1. load welcome.odt in editor (http://www.webodf.org/demo/ci/webodf-0.4.2-1155-g06be704/editor/localeditor.html)
2. move cursor into first list-item ("based on the internationally...")
3. hit enter 5 times, that will create empty list-items (which will contain text:p and editinfo)
4. try to move cursor into one of the empty list-items with a mouse-click

observation:

1. it seems impossible to position the cursor there with the mouse

expected behaviour:

1. "should work" ;)

E.g. check for things like relying on order of keys, like with forEach

See e.g. http://webodf.org/demo/slides/Viewer.js/#../libreoffice-2013-odfautotests.odp

Changing a paragraph style does not seem to count as editing. So no modification indicator is shown.

When you click the annotation button multiple times without doing anything in between, you'll get badly nested annotations.

We should disable the possibility to add annotate annotations.

writeEntry(entry) in lib/core/Zip.js just writes the data uncompressed, ignoring the entry.compressed property

Resulting files seem okay from standard POV, but are quite large.

Seems the css does not add quotation marks for space-less names

For example the "lucida grande" font shown in the font-selector shows serifs for me in firefox, while it looks more like an Arial when actually applied. There is a mismatch which should be resolved. It is obviously wrong in one place:

reproduce:

1. create an annotation
2. put the cursor in front of the annotation
3. press Delete

observation: Delete has no effect

expectation: the first character of the annotated text should be deleted

Editing the size in the font-size textfield is disabled. It is still possible to select the size.
Is that easily disabled?

Observation shows that the selectability also suggests editability, which caused confusion because it is not editable.

If there is an annotation between the current cursor position and the end of the paragraph, pressing Ctrl+Shift+Down to select all content until the paragraph end will not yield the expected result.

http://www.phpied.com/async-javascript-callbacks/ : "BTW, notice that IE is the only browser that fires window.onload before the onload of the (slow) script. This is another thing to keep in mind and look out for."

Proposed solutions: either assert existence of global "require" in boot() or even wait for it by active polling (active polling similar as we did for waiting for the nowjs object)

Currently if the cursor is before or at the position of an annotation start, inserted text will be not added to the annotation. If the cursor is at the position of the annotation end, inserted text will be inserted before the annotation end, thus also part of what is annotated.
An exeption is done if the annotation starts at the start of a paragraph, in that case text inserted at the start will be included in the annotated range.

But if the start and the end of the annotation are at the same position, currently any text inserted at the same position will not be added to the annotation.

LO seems to solve that by having two positions at the start of a paragraph, one before the annotation, so inserted text will stay outside of the annotation range, and one position inside the annotation, so inserted text will be inside the annotation range. Can be seen by moving the cursor towards the begin of an annotated text, e.g. two cursor-right presses are needed to move the cursor from the letter before the annotated range to after the first letter in the annotated range.

using the arrow-down or arrow-up keys while the font-size-textfield has
focus yields a very odd behaviour.
the effect is that the font-size increases step by step until it reaches some maximum or minimum (like 96 or 6).

We want to be able to create lists (even etherpad has that feature).
There are bulleted and numbered lists.

One option would be to bind that to certain paragraph styles.
For example a paragraph style could be:
[ ] none
[x] numbered
[ ] bulleted

That brings up the questions:

• is there a difference for the user between some list-items without bullet/numbering and just some paragraphs?
• would it make sense to hook the list property to paragraph styles (being a list or not)?

A follow-up question would be related to the user-expectation of what happens when the user is in an empty list with a bullet/number and hits backspace. I observed a test-user expecting the bullet/number to disappear. Would that cause the list-item transform to a paragraph?

Splitting a paragraph at the end of an annotated text area results in broken model:
the annotation-end tag is before the cursor, not after the cursor. The created annotationHighlight span is before the annotation-end tag, but for that reason does not catch the cursor and any new inserted text

How to reproduce:

1. Open the welcome.odt with the sample annotations
2. Put the cursor behind the "s" of the annotated text "translate the documents"
3. Press "Return"
4. See the mess in the inspector

Similar problem also with splitting paragraph at the end of a span, new paragraph gets an empty span at the beginning

The editor should know who you are. Also annotations will benefit from that
and might deliver more usefull results than:

<dc:creator editinfo:memberid="localuser"></dc:creator>

For that reason there should be a way to set this kind of information
and also some UI part for entering it.

reproduce:

1. load http://www.webodf.org/demo/ci/webodf-0.4.2-1155-g06be704/editor/localeditor.html
2. create a new annotation and note how your name does not appear in it's title

Is it considered a bug if an empty text:span is left behind?

reproduce:

1. load welcome.odt (http://www.webodf.org/demo/ci/webodf-0.4.2-1160-g8c8a8c0/editor/localeditor.html)
2. move cursor into italic word webmail in first paragraph
3. hit enter twice + hit backspace twice
4. observe the empty span at the word-split-point

1. open welcome.odt in localeditor.html
2. select "That means that" (3rd paragraph) with the mouse from left to right.
3. after doing the selection the cursor will be after "that".
4. creating an annotation from that situation will create an uneditable annotation. (it will also not put the cursor in the annotation)

(this seems to always happen when starting a selection at the start of a paragraph or heading)

If e.g. a text is selected with both bold and non-bold text, the Bold button shows "non bold". Ideally it should show a "some is bold", using a special third state, to properly reflect the state.
Same with the rest of the toolbar.

Fonts which are only loaded on demand result in empty lines in the font picker.
There is no UI feedback that these fonts are actually loaded.

So yet-to-be-loaded fonts should not be displayed, and there should be an indicator that more fonts are loaded ATM.
Once a font is loaded it should be added also to the list in the opened font picker.

(effect shows in chrome, but not in ff)
using a button from the toolbar (e.g. font-size or B/I/U) will scroll to the top if previous scoll position was bottom.

reproduce:

1. load http://www.webodf.org/demo/ci/webodf-0.4.2-1161-g885e99a/editor/localeditor.html
2. resize your browser so that you can vertically scroll
3. scroll to the bottom (and optionally place the cursor on the last line)
4. click "B" button
5. observation: canvas "jumps" to the top

A new test has been added by @peitschie to failingtests.xml, see 6a1314b.

The two subsequent inserts have no effect.

This look like a major regression. In particular, the space character is a culprit, because without it the insertion works fine.

It would be nice to know that a certain font is only rendered with a substitute on the current system, due to not being available there.

Sometimes you want to follow what somebody else is doing.
So there should be a mode where the visible part of the document will always be adapated not the own, but another cursor of a selected member.

This mode could perhaps be entered/left by an action triggered from the memberlist view.
Leaving could also be triggered by the first own cursor navigation command.

If there is an annotation between the current cursor position and the beginning of the paragraph, pressing Ctrl+Shift+Up to select all content until the paragraph start will not yield the expected result.

not insertBefore(node, node | null | undefined)

Seems that requirement is not met in some parts, thus breaking the editor

1. Click somewhere in the document to position the cursor there.
2. Draw a selection (ideally > 2 lines wide, but I haven't scientifically tested this).

Sometimes it works as expected - the cursor is moved to either end of the selection, depending on the direction. But more often than not, it remains in it's old position.

This is serious because now you cannot select something and delete the text.

When using Bold/Italic/Underline buttons or font-size widget for applying
direct styles without having selected anything:

• it will still reflect the Bold/Italic/Underline or new font-size status
• starting to type will not happen with those styles

expected: typing should happen in the selected style
mitigation: disable those widgets when there is no selection

wanted: a way to remove direct formatting

See peitschie's email: https://open.nlnet.nl/pipermail/webodf/2013-August/000058.html

ODF 1.2 §3.17 Foreign Elements and Attributes says:
"
OpenDocument extended documents may contain elements and attributes not defined by the OpenDocument schema. Elements and attributes not defined by the OpenDocument schema are called foreign elements and attributes. Foreign elements and attributes shall not be associated with a namespace that is listed in tables 1, 2 or 3 of section 1.5.
If a foreign element has a text:h or text:p ancestor element, and is a child element of an element for which the OpenDocument schema permits the inclusion of character data, and if the OpenDocument schema permits the inclusion of character data for all its ancestors up to the text:p or text:h element ancestor element, then the element's content may be interpreted by conforming OpenDocument consumers, and the document itself shall be valid against the OpenDocument schema as if the foreign element's start- and end-tags or its empty- element-tag are removed.
"
ODfUtils.isGroupingElement() does only whitelisting ATM:

if ((/^(span|p|h|a|meta)$/.test(localName) && e.namespaceURI === textns) ||
    (localName === "span" && e.className === "annotationHighlight")) {
    return true;
}

I might have missed/forgotten the content of related discussions on irc/in real life, but I recall there has been some.

So Jos & Aditya or anyone, do you remember any reasons you had for staying with the white-list (besides not needing any new coding effort)?

getPositionInTextNode is very complicated.

Comments:

1. The naming is non-obvious - perhaps getOrCreateTextNodeAtPosition is a better fit. Suggestions are welcome.
2. The cursor rearrangement black magic should be moved into a separate function.
3. It returns an empty text node for further usage, if there is no pre-existing text node at the referenced position. Users of this method then need to remember to clean up this text node if it is not going to be used (say when you create annotations). What would be a better solution here?

the canvas will not grow to accommodate all annotations.

reproduce:

1. load welcome.odt in editor (http://www.webodf.org/demo/ci/webodf-0.4.2-1155-g06be704/editor/localeditor.html)
2. add about 6 new (empty) annotations

observation:

1. the last annotations will not be visible
2. there is no way to scroll to make them visible
3. (slightly out of scope for this bug, but probably the same as #30 - you cannot move the cursor into the annotations by clicking into them)

If webodf is used multiple times in a webpage the CSS rules created for the individual documents may collide.
This can happen as the created selectors often only rely on the style-name attribute, which have a high chance to be the same in different documents, if based on the same template.

Ideas how to nicely limit the CSS rules to a specific webodf subtree are welcome.

reproduce:

1. load welcome.odt in editor (http://www.webodf.org/demo/ci/webodf-0.4.2-1155-g06be704/editor/localeditor.html)
2. select from "It can embed..." up to "A few of the many..." (4 paragraphs)
3. assign style "Heading 1"

behaviour:

1. the paragraph after "A few of the many..." changes to "Heading 1" - if it had the cursor because the whole heading above was selected due to reproduction step 2. and thus the cursor was behind it
2. none of the 4 selected paragraphs changes its style

expected behaviour:

1. the 4 selected paragraphs should change style

Changing font-size (direct style) by editing in font-size-textfield does not work:

every keypress in the font-size-textfield seems to apply the new number already:

• imagine a font-size of "12" and you want to change it to "18".
• you click in the textfield to position the cursor behind the "2"
• you notice that the selection in the document disappears (it's still there somehow)
• you backspace the "2" away
• ISSUE: the textfield loses focus; the change is applied
• you click back into the textfield and enter the "8"
• size "18" is actually applied

When you delete an annotation by clicking on the x, the canvas
will scroll back to where the cursor is.
I observed that a test-user considered that as undesirable behaviour.
The expectation is that only a cursor movement (arrow-keys), entering some text, or using scrollbar would scroll the view.

in firefox it is very easy:

• select some words
• press the Bold button
• the selected words are no longer selected
• press the underline button
• the invisibly selected words become underlined

in chrome:

• select some words
• click on the drop-down arrow of the font-selector but do not select a font
• as soon as you press the Bold-button after that the selection reappears

When you hover over the document's text, the mouse pointer remains the same.
This is probably because Firefox treats text inside non-HTML elements differently UX-wise.

We should force the caret shape on hover then.

Would be helpful to know what the sync status is, i.e. if there are no more local ops which are not yet synced to the server.

Drafted some API for the OperationRouter in commit "Add OperationRouter.getHasLocalUnsyncedOpsAndUpdates/OperationRouter.unsubscribeHasLocalUnsyncedOpsUpdates" in my pullbox branch

Needed:
proposal how to reflect the state in the UI
one existing webodf application will want to show this in their own custom additional UI, so this ideally is not hardcoded directly into the webodf.js or the Editor class, but only added by our sample editor code