Last Comment Bug 507364 - using xf-output with @mediatype in xf-repeat makes all elements irrelevant--none displayed
: using xf-output with @mediatype in xf-repeat makes all elements irrelevant--n...
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: unspecified
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-30 04:59 PDT by Clarke
Modified: 2016-07-15 14:46 PDT (History)
2 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
shows an xf-output with mediatype application/xhtml+xml breaking the display (1.76 KB, application/xhtml+xml)
2009-07-30 05:03 PDT, Clarke
no flags Details

Description Clarke 2009-07-30 04:59:44 PDT
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
Comment 1 Clarke 2009-07-30 05:03:11 PDT
Created attachment 391568 [details]
shows an xf-output with mediatype application/xhtml+xml breaking the display
Comment 2 Clarke 2009-07-30 05:49:34 PDT
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 Philipp Wagner [:imphil] 2009-07-30 10:12:48 PDT
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?
Comment 4 Clarke 2009-07-30 22:05:57 PDT
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 Philipp Wagner [:imphil] 2009-07-31 00:27:52 PDT
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.
Comment 6 Clarke 2009-07-31 13:46:28 PDT
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 David Bolter [:davidb] 2016-02-04 12:20:17 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.