761747 - Thunderbird builds are broken due to nsIDOMHTMLElement update

Status: RESOLVED FIXED

(MailNews Core :: Import, defect)

Description

[Joshua Cranmer [:jcranmer]]

<https://hg.mozilla.org/mozilla-central/rev/28dd33748be5> updated the interface to nsIDOMHTMLElement, which means eudora and outlook importers are no busted.

We really need to find some way to avoid getting busted whenever people update DOM interfaces.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Here's the error message from one of our OSX builders:

Undefined symbols for architecture i386:
  "nsEudoraHTMLImageElement::GetItemType(nsIVariant**)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemId(nsAString_internal const&)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemProp(nsIVariant*)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetItemValue(nsIVariant**)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemType(nsIVariant*)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetItemRef(nsIVariant**)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetItemId(nsAString_internal&)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetProperties(nsIDOMHTMLPropertiesCollection**)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemValue(nsIVariant*)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetItemProp(nsIVariant**)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemScope(bool)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::GetItemScope(bool*)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
  "nsEudoraHTMLImageElement::SetItemRef(nsIVariant*)", referenced from:
      vtable for nsEudoraHTMLImageElementin nsEudoraEditor.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make[7]: *** [XUL] Error 1
make[6]: *** [libs_tier_platform] Error 2
make[5]: *** [tier_platform] Error 2
make[4]: *** [default] Error 2
make[3]: *** [default] Error 2
make[2]: *** [build] Error 2
make[1]: *** [build] Error 2
make: *** [build] Error 2
program finished with exit code 2

Comment 2

[Mike Conley (:mconley) (:⚙️)]

So for nsEudoraHTMLImageElement and nsOutlookHTMLImageElement...is the play to just stub out those missing methods with NS_ERROR_NOT_IMPLEMENTED?

Comment 3

[David :Bienvenu]

yes, like all the other methods. I'll have a whack at it.

Comment 4

[David :Bienvenu]

Attachment: probable fix

this is probably what I'll land - just waiting for my build to finish to make sure it builds.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

I can confirm that this successfully builds on Windows 7.

Comment 6

[David :Bienvenu]

http://hg.mozilla.org/comm-central/rev/2c6b820cbf13

hey, I got rid of the nsIEditor dependency :-) I'll go back and see if there's some way we can deal with the fake dom element classes.

Comment 7

[David :Bienvenu]

My suggestion for getting rid of the import dependency on nsIDOMNode and related classes would be to augment the code the processes the editor embedded object list (nsMsgComposeAndSend::GetMultipartRelatedCount and nsMsgComposeAndSend::ProcessMultipartRelated) to handle nsIMsgAttachmentData objects as well as nsIDomNodes, and have the import code create nsMsgAttachmentData objects. (I may not have the interface/class names exactly right, but the idea is to use our own interfaces/objects.)

I'll file a bug to do so, and maybe have a quick whack at it.