Closed Bug 300870 Opened 19 years ago Closed 18 years ago

Ephemeral message: Does not support src and displays both inline and binding text

Categories

(Core Graveyard :: XForms, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 338135

People

(Reporter: aaronr, Assigned: msterlin)

References

Details

Attachments

(2 files)

Right now if you have an ephemeral message with both a single node bind and
inline text, both will show.  Also, an ephemeral message will not link to an
external resource (via @src).
Attached file testcase
As part of https://bugzilla.mozilla.org/show_bug.cgi?id=300255 I'll be checking
in code that will sniff the external resource (value of the @src) to make sure
that it exists before going off to do all of the work that
nsXFormsMessageElement does when it displays a message.  For ephemeral messages,
it would make sense not to sniff, but rather grab the resource and cache its
contents to later be used in: nsXFormsMessageElement::HandleEphemeralMessage().
 Please consider this while fixing this bug.
Summary: ephemeral message problems → Ephemeral message: Does not support src and displays both inline and binding text
*** Bug 301607 has been marked as a duplicate of this bug. ***
Blocks: 322255
Blocks: 326372
Blocks: 326373
Assignee: aaronr → doronr
So here is what is happening:

NS_IMETHODIMP
nsXFormsMessageElement::GetInsertionPoint(nsIDOMElement **aElement)
{
  NS_IF_ADDREF(*aElement = mVisualElement);
  return NS_OK;
}

GetInsertionPoint returns the visual element that we show/hide, so the text content of the xforms:message is added.

However, DOM3NODE->SetTextContent() does not overwrite that value, so we end up with this bug.  Returning null for GetInsertionPoint makes the testcase work, but obviously won't display inline text anymore.

Any ideas how we should handle this?  Aaron says we have crashers in repeat if we return null in GetInsertionPoint, so not sure if that is safe for message or not.
(In reply to comment #5)
> Any ideas how we should handle this?  Aaron says we have crashers in repeat if
> we return null in GetInsertionPoint, so not sure if that is safe for message 
> or not.

We definately have some problems with that. I think XTF is to blame somehow, and I think it is related to (if not the same as) the crash in bug 330903.
This fails testsuite testcase: 8.3.5.c
Assignee: doronr → msterlin
Status: NEW → ASSIGNED
Linking to an external resource via @src is fixed by the initial patch for bug 338135, but single node binding was not implemented. Because the two bugs are closely related and the fix must work for both, I am duping this bug to 338135.
 

*** This bug has been marked as a duplicate of 338135 ***
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: