[Trinidad] submit blocked on FF after using tr:fileDownloadActionListener
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 onclick=submitform ... are
blocked forever, while buttons marked for partialSubmit
(onclick=TrPage._autoSubmit...) 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
Re: [Trinidad] submit blocked on FF after using tr:fileDownloadActionListener
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 onclick=submitform ...
are blocked forever, while buttons marked for partialSubmit
(onclick=TrPage._autoSubmit...) 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
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] submit blocked on FF after using tr:fileDownloadActionListener
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=realplayermessage.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
Re: [Trinidad] submit blocked on FF after using tr:fileDownloadActionListener
Ok,
thanks.
Now the issue is archived; incase people have (again) problems with
the listener in FF,
we are able to provide them a work around.
Thx,
Matthias
On Thu, Feb 14, 2008 at 11:05 AM, Renzo Tomaselli
[EMAIL PROTECTED] wrote:
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=realplayermessage.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 onclick=submitform ...
are blocked forever, while buttons marked for partialSubmit
(onclick=TrPage._autoSubmit...) 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
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad] submit blocked on FF after using tr:fileDownloadActionListener
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.
-- 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 onclick=submitform ...
are blocked forever, while buttons marked for partialSubmit
(onclick=TrPage._autoSubmit...) 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
