Closed
Bug 507364
Opened 15 years ago
Closed 8 years ago
using xf-output with @mediatype in xf-repeat makes all elements irrelevant--none displayed
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: cray99, Unassigned)
Details
Attachments
(1 file)
1.76 KB,
application/xhtml+xml
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12) Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12) Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12 Testing with xf-output and @mediatype of html/text or application/xhtml+xml, elements will render appropriately when not inside a repeat but break that section of the form when it is inside a repeat. Reproducible: Always Steps to Reproduce: 1.make a repeat with an xf-output and no @mediatype -- will display text 2.add @mediatype with html/text or application/xhtml+xml --nothing displays 3.make sure you have some basic html/xhtml markup in the element (using character entitities). Actual Results: mediatype="application/xhtml+xml" breaks the display. Expected Results: It should render the same as when output with mediatype is used outside a repeat the attachment explains it all
I don't think this is a high priority item, however, the only thing is that you can't really do a workaround that give very near the same effect (when using a very large list of output values (e.g. imagine the attached example with 100+ <text> elements instead of only two).
Comment 3•15 years ago
|
||
There is actually a rather easy workaround: map the "html" namespace prefix to "http://www.w3.org/1999/xhtml", like you did for the "h" prefix. Inside resources/content/xforms-xhtml.xml we insert html:div elements into the code, but for some reason, Mozilla copies the tags and does not resolve the prefix before inserting. That gives the following error on a debug build: XML Parsing Error: prefix not bound to a namespace Location: Line Number 1, Column 197: <h:html xmlns:h="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xf="http://www.w3.org/2002/xforms" xmlns:xs="http://www.w3.org/2001/XMLSchema"><h:body><xf:repeat><html:div><contextcontainer xmlns="http://www.w3.org/2002/xforms"><xf:output><span xmlns="http://www.w3.org/1999/xhtml"> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^ JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://xforms/content/xforms-xhtml.xml :: anonymous :: line 195" data: no] Looks like a XBL bug to me?
Status: UNCONFIRMED → NEW
Ever confirmed: true
In order to make xforms useable, accessable, and relevant, the only acceptable workarounds are those that can be done with xforms markup itself. Asking all my clients to go in and manipulate their Firefox/and or xforms extension is not practical, but I do hope, as you say, it's only an xbl problem, that is something that might be more in our control than, say, something like an innerhtml problem.
Comment 5•15 years ago
|
||
This is a bug of course, and it will be fixed. But, in the meantime, the workaround only involves changing your XForms: add a xmlns:html="http://www.w3.org/1999/xhtml" attribute to your root element in your form.
Phillip, Thanks very much. I misunderstood; the "resources/content/xforms-xhtml.xml" comment threw me and I thought you were saying to do both steps as a workaround. I get the rest of what you were saying now. this is a VERY simple workaround and thank you for the heads-up! (this was a real key for improving my application. Thanks again!!
Comment 7•8 years ago
|
||
RIP xforms
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Assignee | ||
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
•