Yes, it's a plugin issue. I got it after googling around for a while,
it seems a well known issue together with many other side-effects I
didn't see (yet).
All of this already reported to them, see
http://real.lithium.com/real/board/message?board.id=realplayer&message.id=18560
-- Renzo
Matthias Wessendorf wrote:
Hi,
On Thu, Feb 14, 2008 at 10:47 AM, Renzo Tomaselli
<[EMAIL PROTECTED]> wrote:
Well - according to some net browsing - the responsability for this odd
behavior is of the RealPlayer Browser Record plugin.
After disabling it - everythings runs as expected.
Btw, there was nothing apparently wrong with submitForm. Calling
form.submit() had simply no followup, while PPR still worked.
so, that is a bug in the plugin, isn't it?
Perhaps you can report that to them ?
-M
-- Renzo
Renzo Tomaselli wrote:
> Hi, for the purpose of saving a document on a page, I used
> tr:fileDownloadActionListener such as in:
>
> <tr:commandLink id="blobSave">
> <tr:icon name="bitconsSave"/>
> <tr:fileDownloadActionListener filename="#{prop.blobName}"
> contentType="application/octet-stream"
> method="#{prop.blobSave}"/>
> </tr:commandLink>
>
> where contents are achieved from the bean:
>
> public void blobSave(FacesContext context, OutputStream out)
> throws IOException {
> byte[] v = ((BlobRow)value).getValue();
> out.write(v);
> }
>
> everything works fine on IE, while on FF it runs just once: after
> saving (or cancelling), all buttons featuring
> are blocked forever, while buttons marked for partialSubmit
> () work properly. Then other buttons
> are enabled again, but using the above link once the game restarts.
> No errors. I'm using Trinidad 1.05. I'm about to debug the js
> machinery after submitform.
>
> -- Renzo
>
>
|
