570624 - "ASSERTION: called nsGenericElement::SetText"

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: called nsGenericElement::SetText: 'Error', file /builds/moz2_slave/mozilla-central-macosx-debug/build/content/base/src/nsGenericElement.cpp, line 4954

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: stack

In nsTextControlFrame::UpdateValueDisplay rootNode is

div@0x7f8260952be0 class="anonymous-div" intrinsicstate=[00020000] flags=[02200539] primaryframe=0x7f8261aa0680 refcount=7<
  br@0x7f8260952d30 _moz_editor_bogus_node="TRUE" _moz_dirty="" intrinsicstate=[00020000] flags=[02200111] primaryframe=0x7f826ac0a3c8 refcount=3<>
>

and we call SetText on textContent which is the br node.

Comment 2

[Timothy Nikkel (:tnikkel)]

Is this a regression from bug 534785?

Comment 3

[(no longer active)]

(In reply to comment #2)
> Is this a regression from bug 534785?

Yes.  And also yes.

(The second yes is the answer to the next obvious question: "Do you have a patch?") ;-)

Comment 4

[(no longer active)]

Attachment: Patch (v1)

I was getting the editor from the text control frame inside the AttributeChange handler on the frame.  If the editor was being initialized for the first time, we'd get into a situation where the editor was initialized, but mUseEditor was false.  The editor added the bogus br node, but we thought that there was no editor around, so the we'd get more calls to UpdateValueDisplay.

Comment 5

[(no longer active)]

Attachment: Patch (v2)

Actually I found one more similar case in nsTextControlFrame, so let's fix that as well.

Comment 6

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/3869cf687c26