using xf-output with @mediatype in xf-repeat makes all elements irrelevant--none displayed



9 years ago
2 years ago


(Reporter: cray99, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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

Comment 1

9 years ago
Created attachment 391568 [details]
shows an xf-output with mediatype application/xhtml+xml breaking the display

Comment 2

9 years ago
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).
There is actually a rather easy workaround: map the "html" namespace prefix to "", 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
Line Number 1, Column 197:
<h:html xmlns:h="" xmlns:ev="" xmlns:xf="" xmlns:xs=""><h:body><xf:repeat><html:div><contextcontainer xmlns=""><xf:output><span xmlns="">

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?
Ever confirmed: true

Comment 4

9 years ago
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.
This is a bug of course, and it will be fixed. But, in the meantime, the workaround only involves changing your XForms: add a 
attribute to your root element in your form.

Comment 6

9 years ago
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!!
RIP xforms
Last Resolved: 3 years ago
Resolution: --- → WONTFIX


2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.