Hi,
I think I found a bug in Chrome (https://code.google.com/p/chromium/issues/detail?id=330687 ), but was wondering if Orbeon could maybe work around the problem. Maybe it’s not a bug in Chrome, or it might take a while before it is fixed (note that it fails in Safari also, but works in Firefox and Internet Explorer).
The problem:
- How to reproduce o Deploy the attached orbeon app (see “postpdf-app.zip”). o Open http://localhost:8080/orbeon/postpdf/index in Chrome o Click Submit - Observed behavior o The IFRAME contains a dark-gray rectangle (see “bad.png”) - Expected behavior o The PDF is displayed (see “good.png”)
I use: - Chrome 31.0.1650.63 m - Orbeon 4.3.0.1.201308150213-CE - Apache tomcat 7.0.26
The XForm contains a submit that returns a PDF and the target is set to the IFRAME. It is of course the Orbeon Server that performs the submission, the browser just submits the HTML form to the Orbeon Server. The bug in Chrome seems to be hit when the HTML form is submitted to the same URL as the current page (this is done in resources-packaged/ops/javascript/orbeon/xforms/server/AjaxServer.js: requestForm.action = window.location.href;).
A workaround could be to make sure the URL is slightly different (see “workaround.patch.txt”). But maybe there’s something else going on that I didn’t think of, or there might be a better workaround/solution.
Thanks in advance,
Tars Joris Development Manager Inventive Designers Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer -- You received this message because you are subscribed to the Google Groups "Orbeon Forms" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. workaround.patch.txt (2K) Download Attachment postpdf-app.zip (2K) Download Attachment bad.png (95K) Download Attachment good.png (107K) Download Attachment |
Administrator
|
Hi Tars,
Thank you for the detailed instructions, the reproducible example, and for filling a bug against the Chromium project. This indeed looks like a Chrome/WebKit bug. I can't think of a simple workaround you could do, but I gather you have a workaround in the form of the patch you submitted. We'll have to think a bit more about the change you suggested before we put it in. We don't want to arbitrary pollute URLs, especially when they are visible to users. Maybe we could add something to the URL only if there is a target and the target corresponds to the id of an iframe in the page. Or we could let the XForms author set the URL through an additional xxf:… attribute. In the meantime, I've also created a bug on our side to track this: https://github.com/orbeon/orbeon-forms/issues/1480 Alex
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Hi Alex,
Thank you for your response. I agree that the workaround is not desirable, but we'll refine it (only modify URL when the target is an IFRAME) and use it on our local repository until there's a fix in Chrome, or a better workaround is available. Cheers, Tars |
Administrator
|
Tars,
OK, sounds good, and we'll let you know through this thread what we plan to do about this in our code when we get a chance to discuss this internally here. Alex
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Administrator
|
Hi Tars,
FYI, this is now fixed, and the fix will be in the upcoming 4.5 by default. https://github.com/orbeon/orbeon-forms/issues/1480 Alex
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Hi Alex,
That's great. Thank you. We'll upgrade and revert our fix when the release is out. Tars |
Free forum by Nabble | Edit this page |