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)
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).
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.
Updated•19 years ago
|
Summary: ephemeral message problems → Ephemeral message: Does not support src and displays both inline and binding text
Comment 4•19 years ago
|
||
*** Bug 301607 has been marked as a duplicate of this bug. ***
Comment 5•18 years ago
|
||
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.
Comment 6•18 years ago
|
||
(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.
Comment 7•18 years ago
|
||
This fails testsuite testcase: 8.3.5.c
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•18 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•