Closed Bug 402573 Opened 13 years ago Closed 11 years ago

Error: a._updateVisibleText (was a._setNewlineHandling) is not a function (e.g. trying to edit mailing list)

Categories

(Toolkit :: XUL Widgets, defect)

1.9.0 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: mkmelin, Unassigned)

References

Details

(Keywords: regression)

When running thunderbird (trunk), e.g. opening a mailing list causes some exceptions, I get one for each address. 

Error: a._setNewlineHandling is not a function
Source File: chrome://global/content/bindings/textbox.xml
Line: 143

Broke 2007-10-19 -> 2007-10-20
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-19+03%3A00%3A00&maxdate=2007-10-20+04%3A00%3A00&cvsroot=%2Fcvsroot
(In reply to comment #0)
> When running thunderbird (trunk), e.g. opening a mailing list causes some
> exceptions, I get one for each address. 
> 
> Error: a._setNewlineHandling is not a function
> Source File: chrome://global/content/bindings/textbox.xml
> Line: 143

I've just tried this on SeaMonkey trunk.

I get the error twice the second time and twice every subsequent time I open the mailing list dialog (but only if the mailing list dialog has addresses in it).

Looks like a regression from bug 321000 as that is the one that recently created this function.

luser - any ideas?
Blocks: 321000
Hm.  Perhaps something creates a textbox and deletes it before the setTimeout fires?  I'm not really sure what's happening here.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007110906 Calendar/0.6a1

Same error occurs a lot in Sunbird (trunk) e.g. when switching the calendar views fast. As far as I know each eventbox displayed in the calendar view contains a hidden textbox element that will be displayed during inline editing. Fast switching of the views will create and delete the textbox elements a lot.
Ah, that would make sense.  What we could probably do is add a check inside the anonymous function there in the setTimeout call, to ensure that the object is still valid.
Based on comment 0, comment 1 and comment 3 this is a problem with Toolkit's textbox.xml and not specific to the address book. Therefore moving to a more appropriate component.
Component: Address Book → XUL Widgets
Product: Thunderbird → Toolkit
QA Contact: address-book → xul.widgets
The same error shows in our XULRunner application several times. I havn't found the origin so far.
XULRunner version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9b2pre) Gecko/2007111510
Same problem with Firefox3b2pre when trying to edit a long attachment ("edit attachment as comment").
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020919 Calendar/0.6a1

Using the steps from comment #3 I now see the following error message instead of the message mentioned in comment #0:

    Error: a._updateVisibleText is not a function
    Source File: chrome://global/content/bindings/textbox.xml
    Line: 206
a._updateVisibleText was added by bug 406095.
Summary: Error: a._setNewlineHandling is not a function (e.g. trying to edit mailing list) → Error: a._updateVisibleText (was a._setNewlineHandling) is not a function (e.g. trying to edit mailing list)
Different line number in XulRunner Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008061013

Error: a._updateVisibleText is not a function
Source File: chrome://global/content/bindings/textbox.xml
Line: 208
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) Gecko/2008070708

also reports:

Error: a._updateVisibleText is not a function
Source File: chrome://global/content/bindings/textbox.xml
Line: 208
The piece of code causing this trouble ist that:

      <constructor><![CDATA[
        var str = this.boxObject.getProperty("value");
        if (str) {
          this.inputField.value = str;
          this.boxObject.removeProperty("value");
        }

        // this.editor may not be initialized yet in
        // bindings that inherit from xul:textbox, so
        // do this after construction
        setTimeout(function (a) {
          a._updateVisibleText();
          a._setNewlineHandling();
        }, 0, this);
      ]]></constructor>

The binding has a _updateVisibleText method defined, so this should not happen, but for unknown reasons it does happen. The variable "a" inside the timeout handler looks like this, which looks like partially constructed:



[object XULElement]

ATTRIBUTE_NODE = 2
CDATA_SECTION_NODE = 4
COMMENT_NODE = 8
DOCUMENT_FRAGMENT_NODE = 11
DOCUMENT_NODE = 9
DOCUMENT_POSITION_CONTAINED_BY = 16
DOCUMENT_POSITION_CONTAINS = 8
DOCUMENT_POSITION_DISCONNECTED = 1
DOCUMENT_POSITION_FOLLOWING = 4
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 32
DOCUMENT_POSITION_PRECEDING = 2
DOCUMENT_TYPE_NODE = 10
ELEMENT_NODE = 1
ENTITY_NODE = 6
ENTITY_REFERENCE_NODE = 5
NOTATION_NODE = 12
PROCESSING_INSTRUCTION_NODE = 7
TEXT_NODE = 3
align = 
allowEvents = false
appendChild = [function]
attributes = [object NamedNodeMap]
baseURI = chrome://ida/content/windows/dialogs/actionDlg.xul
blur = [function]
boxObject = [object BoxObject]
builder = null
childNodes = [object NodeList]
className = tree-input
click = [function]
cloneNode = [function]
collapsed = false
compareDocumentPosition = [function]
contextMenu = 
controllers = [object XULControllers]
database = null
datasources = 
dir = 
dispatchEvent = [function]
doCommand = [function]
firstChild = null
flex = 
flexGroup = 
focus = [function]
getAttribute = [function]
getAttributeNS = [function]
getAttributeNode = [function]
getAttributeNodeNS = [function]
getBoundingClientRect = [function]
getClientRects = [function]
getElementsByAttribute = [function]
getElementsByAttributeNS = [function]
getElementsByClassName = [function]
getElementsByTagName = [function]
getElementsByTagNameNS = [function]
getFeature = [function]
getUserData = [function]
hasAttribute = [function]
hasAttributeNS = [function]
hasAttributes = [function]
hasChildNodes = [function]
height = 
hidden = true
id = 
insertBefore = [function]
isDefaultNamespace = [function]
isEqualNode = [function]
isSameNode = [function]
isSupported = [function]
lastChild = null
left = 0
localName = textbox
lookupNamespaceURI = [function]
lookupPrefix = [function]
maxHeight = 
maxWidth = 
menu = 
minHeight = 
minWidth = 
namespaceURI = http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul
nextSibling = null
nodeName = xul:textbox
nodeType = 1
nodeValue = null
normalize = [function]
observes = 
ordinal = 
orient = 
ownerDocument = [object XULDocument]
pack = 
parentNode = [object XULElement]
persist = 
prefix = xul
previousSibling = [object XULElement]
ref = 
removeAttribute = [function]
removeAttributeNS = [function]
removeAttributeNode = [function]
removeChild = [function]
removeEventListener = [function]
replaceChild = [function]
resource = null
setAttribute = [function]
setAttributeNS = [function]
setAttributeNode = [function]
setAttributeNodeNS = [function]
setUserData = [function]
statusText = 
style = [object CSSStyleDeclaration]
tagName = xul:textbox
textContent = 
tooltip = 
tooltipText = 
top = 0
width = 
If you look for a.__proto__ you get "xpconnect wrapped native prototype". Because of stupid wrapping the original XULElement defined in a binding is truncated to the  API a plain XULElement. This causes the method _setNewlineHandling to disappear.

The problem of __proto__ being "xpconnect wrapped native prototype" is also reported here:

http://mootools.lighthouseapp.com/projects/2706/tickets/149-greasemonkey-support
This affects Thunderbird and Lightning, so adding tb3needs status whiteboard.
Whiteboard: [tb3needs]
OS: Linux → All
Hardware: PC → All
This generates a _tremendous_ amount of error spew in the Thunderbird console, to the point where real error stuff in the console is likely to get lost in the sea of these errors.  Requesting blocking-1.9.1 as a result.

Georg, they seem to 

Adding sicking and bz to the CC of the bug in the hopes that they can use the information from comments 13 and 14 to suggest a line of attack...
Flags: blocking1.9.1?
No idea why the wrapper stuff would be going awry, but does not passing the object as an arg work?  That is, just using:

 var a = this;

and then using |a| in the function without having it as an argument (so you get a closure)?

On the other hand, this doesn't happen for every textbox, right?  To me that suggests that the wrapper stuff is not a problem here, and that the original hypothesis that the timeout runs after the binding has been detached is correct.  The fix for _that_ would be checking in this code whether |a| has the methods you plan to call.
What bz said makes sense to me. Is the textbox (or one of its parents) removed from the document somewhere?
FYI:
I'm working on toolbar customization in SeaMonkey. I encountered this when
moving the urlbar (which contains a textbox) from one toolbar to another. I borrowed the following wallpaper patch from firefox:

#wrapper-urlbar-container > #urlbar-container> #nav-bar-inner > #urlbar {
  -moz-user-input: disabled;
}

I get this error when moving the urlbar off the toolbars and into the palette:
Error: this.editor is null
Source file: chrome://global/content/bindings/textbox.xml
Line: 154

I wallpapered over this using:

#BrowserToolbarPalette > #urlbar-container > #nav-bar-inner > #urlbar {
  -moz-binding: none;
}
Maybe the fix is to have the destructor cancel the timeout? Seems like a sensible thing to do no matter what
Dão's got a patch up in bug 472302 to simply get rid of the problematic timeouts.
Depends on: 472302
fixed by bug 472302, which doesn't have approval for 1.9.1 yet.
Target Milestone: --- → mozilla1.9.2a1
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Version: Trunk → 1.9.0 Branch
Flags: blocking1.9.1?
Whiteboard: [tb3needs]
You need to log in before you can comment on or make changes to this bug.