275175 - changing value of a text node cancelled by the editor

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect)

Description

[Eyal Rozenberg]

I run the following code:

editor.beginTransaction();
// ... get some text node within the document in the variable myNode
mynode.nodeValue = "blahblah";
jsConsoleService.logStringMessage(mynode.nodeValue);
editor.endTransaction();

the console shows "blahblah" as the nodeValue of myNode; but when this code
runs, the text in the editor window does not change at all. And using DOM
Inspector I find that the value of the node I changed has reverted to the
original one and is not "blahblah".

Comment 1

[Boris Zbarsky [:bzbarsky]]

Shouldn't you be using the transaction mechanism to change the nodevalue?

Comment 2

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #1)
> Shouldn't you be using the transaction mechanism to change the nodevalue?

good question indeed. The code asks the editor to batch transactions but there
is not transactions executed between |beginTransaction()| and |endTransaction()|

Comment 3

[Eyal Rozenberg]

Uh, excuse the rude question, but what are you talking about? Quoting the
documentation,

"BeginTransaction is a signal from the caller to the editor that the caller will
execute multiple updates to the content tree that should be treated as a single
logical operation, in the most efficient way possible.
All transactions executed between a call to beginTransaction and endTransaction
will be undoable as an atomic action.
endTransaction must be called after beginTransaction."

I'm updating the content tree in a way that should be treated as a single
logical operation. That's all the beginTransaction() and endTransaction() here
should mean. Even if they have some other siginificance, there is no _way_ the
changes I make should be undone when I endTransaction(). Especially if they have
been applied when I do the logStringMessage().

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

> All transactions executed between a call to beginTransaction and endTransaction
> will be undoable as an atomic action.

Excuse the rude answer, but you should make sure you understand the
documentation before quoting it.

Where do you see a transaction in your code ? I see only a direct DOM
modification. This kind of operation has to be performed through the transaction
manager to be a transaction...
See mozilla/editor/libeditor/base/*Txn.h for transactions available through the
editor. See |nsEditor::CreateNode()| for an example. That would become
|editor.createNode()| in JS.

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

To replace some text by some other text, select the first one and use an
InsertTextTxn transaction.

Comment 6

[Eyal Rozenberg]

Regardless of whether you prefer that I change text that way, the behavior I
described is still inconsistent. Please let me reopen the bug.

Comment 7

[Eyal Rozenberg]

The way I understand the documentation, whatever changes you make between
begin/endTransaction, are a transaction. Maybe I'm wrong but that _is_ the
literal meaning of the function names, isn't it?

Anyway, it seems that at endTransaction it says that 

"beginUpdate must be called before endTransaction is called."

is my chang being undone because of the lack of beginUpdate() calls? Because in
BiDi Mail UI We have lots of other code which does updates within
begin/endTransaction() calls and does not call
beginUpdate - yet it works. As it should, I believe.

Anyway, regardless of what constitutes a transaction - either the
logStringMessage() won't show the change, or it won't be undone by the
endTransaction(). The combination of these two is inconsistent.

Comment 8

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #7)
> The way I understand the documentation, whatever changes you make between
> begin/endTransaction, are a transaction. Maybe I'm wrong but that _is_ the
> literal meaning of the function names, isn't it?

File a bug to fix the documentation then.

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #6)
> Regardless of whether you prefer that I change text that way, the behavior I
> described is still inconsistent. Please let me reopen the bug.

Not without further advice from the Transaction Master, Kin Blas.

Kin, the bug as described is invalid since the TxnMgr can't see the direct DOM
call; but reporter says editor.endTransaction() clobbers the direct DOM change
he made on the tree. Opinions ?

Comment 10

[Eyal Rozenberg]

I'll file a bug about those method names and their documentation, definitely.
Still, it is inconsistent for the node value to be changed, then for the change
to be undone just because I call endTransaction(). If the change is held back
than let it be held back all the way.