Don’t really know how to do a check on this issue.
I was on a https; secure checkout, the last stage for payment, payment authorization.
Confirm button was dead.
I tried with both the default JDK and latter with the SUN Java versions from Non-Oss
Neither worked
So I switched browser to Seamonkey and all was good.
On 03/15/2011 08:36 PM, caf4926 wrote:
>
> Confirm button was dead.
i assume you are using a beta browser?
don’t you know you should expect to find problems when you use
pre-release/TESTING software? 
is seamonkey also a beta?
if not, maybe all you need to do is log a bug?
–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11
Seriously
You come back at me with that DD.
Does the site really use the Java plugin? Very few sites need Java these days. Are you confusing Java with Javascript?
Obviously this is going to be hard to try again, but next time it happens, use the debugging addon Firebug to examine the DOM to see what happened to the button.
It could be a transient error and would have worked next time. It could also be poorly written Javascript on the site, these things happen.
If we follow “the letter of the law”, then the OP is using a “test” release of Firefox. If we consider the report in a somewhat wider view, the packaging of Firefox 4.0beta with the openSUSE 11.4 supported release might tend to add a certain de facto air of legitimacy to the concern.
Of course, the OP is most certainly aware of the status, though the many others rapidly downloading and installing 11.4 face the same potential problems.
More simply said: openSUSE 11.4 should have been released with Firefox 3.6.15 (or whatever was current on the release date).
On 03/15/2011 10:06 PM, caf4926 wrote:
>
> Seriously
> You come back at me with that DD.
oh, i didn’t notice it was you! or would’a said Sir!
i know i should’s quiet because i have no idea…well, actually i do
but i JUST thought of it can’t a java VM problem since seamonkey would
also fail, so must be a javascript problem i guess a problem with the
way beta 4 is handling the script…
well, let me ask, was it a java app, or java script that failed…can
you share with us the site … and i’ll have a look at it…
–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11
On 03/15/2011 10:36 PM, SeanMc98 wrote:
> More simply said: openSUSE 11.4 should have been released with Firefox
> 3.6.15 (or whatever was current on the release date.
i do not disagree, but i also do not make the decisions around
here…if i did a current (non-beta) firefox would have been default
installed…
at the very most i might could have been arm twisted to allow the
installing user to be given a CHOICE between beta and not…
–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11
Not if like me SeaMonkey (not beta) always gets installed quickly after install. 
I agree with your final comment, but imagine the whining and crying if FF 4 hadn’t been included. 
True. Early in my installs (immediately after the automatic updates), I installed Firefox 3.6.15!
I can imagine reading the tirades, diatribes and pummeling potpourri … it might have been interesting reading for about 30 seconds !
I do agree with DenverD: I think a choice of FF 3.6.15 or FF4.beta would have been preferable.
Hi,
I’m also seeing unpredictable non fatal behaviour in FF and nearly every day get a new file hs_err_pidxxxx.log.
The file size can vary in size from 1,5k upto 120k. It always indicates a Java Runtime Environment error.
I’m assuming these error are due to using beta SW.
Here is the smallest one, just for info. I expect you have something similar.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f3638701952, pid=3671, tid=139870278280960
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.7
# Distribution: Dummy Product (x86_64), package suse-1.2.1-x86_64
# Problematic frame:
# C [libuno_cppu.so.3+0x1a952] uno_type_sequence_construct+0x54
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00000000018ee800): JavaThread "Thread-43" daemon [_thread_in_native, id=3727, stack(0x00007f3616306000,0x00007f3616407000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000
Registers:
RAX=0x4545454545454545, RBX=0x0000000000000002, RCX=0x0000000000000002, RDX=0x0000000000000000
RSP=0x00007f3616405340, RBP=0x00007f36164053c0, RSI=0x0000000000779500, RDI=0x00007f36164053c0
R8 =0x00007f363893aba0, R9 =0x0101010101010101, R10=0x0000000000000006, R11=0x0000000000000206
R12=0x0000000000000000, R13=0x00007f363893aba0, R14=0x00007f36164053c0, R15=0x0000000001d7a7b8
RIP=0x00007f3638701952, EFL=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000000
TRAPNO=0x000000000000000d
Register to memory mapping:
RAX=0x4545454545454545
It will be tricky for you folks to go and check, because as I said, I was on https. Final part of the payment. Card details entered. ‘Confirm’ button on hover referred to javascrip
This is the site anyway: Please enable your cookies
I thank you all for your comments. And yes, I think I know the score in all respects. My post here was more of interest than anything.
FYI: I did try the checkout more than one time.
Funny thing this: I often find seamonkey better on secure checkout than firefox, even than FF3. I actually have it set to handle some of my online grocery shopping checkouts.
Yes. I think FF3 should have been shipped in 11.4
I could, but have not switched back.
Once in a couple of months I get a report from a user that a webapp I maintain says their browser is not accepting cookies. It’s very hard to reproduce and nearly always goes away when the browser or machine is restarted. There are various possibilities including a rare logic error in the site re cookies, clock skew or selective blocking of cookies from my site (IE jinks), but I have to put such reports in the too hard bin.
Webapps are very complicated, and worse when standards are not followed, even if inadvertently on the part of the developer and/or browser.
That was odd that the URL came up that way ‘Please enable your cookies’
They are of course.
Fortunately, with choice at my fingertips, all went well with Seamonkey.
Thanks for your always invaluable and timeless advice @ken_yap