The code I pasted is from prototype.js, and I didn't write the code.
There seems to be an IE8 error, when prototype.js is defining
getElementsByClassName.
I just used magento, with wowslider, and got this error. I'm not sure
where it is coming from.
On Jun 8, 8:53 pm, Jason Westbrook
Hi,
Is your application running on some kind of intranet network?
This seems close to an issue we got with IE9 and I wouldn't be
surprised if the issue was already present on IE8.
Basically, (and for some reason only known from MS), when on a
Trusted Site IE9 revert to compatibility mode, which
Unless you're getting paid by the hour, you loose nothing by temporarily
trying a later version of prototype. Try eliminating the easy stuff before
working on the hard and you'll avoid that headslap moment that comes when
you realize you wasted two weeks for nothing.
On Dec 15, 2011 3:35 PM,
Thanks for the suggestion. That's an option that we plan to do with
the next Production release. Unfortunately, we have release cycles
that we have to adhere to and in the mean time, the client is unhappy
with getting these 12XXX status code errors. I have also done a diff
between version 1.4.0
Hi,
Anyone please help. What am I do wrong?!!
You're using the same `id` value on more than one element. That is
invalid markup[1] and will not work correctly. `id` values *MUST* be
unique on the page.[2][3]
You may have wanted to use a `class`[4][5] instead:
div class=num1/div
div
Hi,
I would say that it comes from your ids.
In fact, an id should be unique in a page. You should use class
instead when you want several object to have the same behaviour.
To access them, simply do $$('.num') and in your div's, change id=num
by class=num (it's a good practice to put s as you
T.J. and Julien Thank you
On Jun 23, 3:17 pm, Julien Lenne tyrsen...@gmail.com wrote:
Hi,
I would say that it comes from your ids.
In fact, an id should be unique in a page. You should use class
instead when you want several object to have the same behaviour.
To access them, simply
On 2/15/2010 3:33 AM, gwyohm wrote:
hi,
why not using prototype cross-browser document.viewport methods ?
document.viewport.getHeight()
simple answer: still learning.
I very much appreciate the suggestion !
--
Bill Drescher
william {at} TechServSys {dot} com
--
You received this message
hi,
why not using prototype cross-browser document.viewport methods ?
document.viewport.getHeight()
On 13 fév, 14:32, bill will...@techservsys.com wrote:
On 2/13/2010 8:05 AM, Alex McAuley wrote: you dont need the quote before
hand ...
$('leftPane').style.height = '' + ((.99 *ah)-20 ) +
Hi Mostafa,
What line have an invalid argument ?
And what is the function trying to do? means which style is trying to
be modified ?
--
david
On 10 nov, 15:46, Mostafa ms.a...@gmail.com wrote:
Hi,
i have a problem when working with iGoogle style drag and drop
portlets on ie8
my code runs
Hi Jason,
the way you write it is good even in IE.
When write onComplete: parent_response() , you launch the function
at initialisation time, and the AJAX was not call, so you input is
undefined. If you test alert(originalRequest) you should also have
undefined.
When should this be
On 09/18/2009 06:43 AM, david wrote:
Hi Jason,
In fact by writting parent_response(), it indicate that you execute
the function on the creation of the AJAX request, and the retruned of
the execution of the function value will be used for the onComplete.
So the onComplete value will be
On 09/18/2009 03:00 PM, Jason Frisvold wrote:
via IE8? It returns nothing. I tried adding:
alert($H(originalRequest).inspect()); to the parent_response method and
the alert never shows up when running via IE8.
I have discovered more.. Adding an onException block like this :
function
AHA!!!
I have resolved this.
We had a base element in the head of the document. Apparently this is
to reference where the images/css/etc are. This causes IE8 to prevent
javascript from retrieving a page due to security restrictions.
I'd feel dumb about it if I didn't think this was a really
Hi Jason,
the way you write it is good even in IE.
When write onComplete: parent_response() , you launch the function
at initialisation time, and the AJAX was not call, so you input is
undefined. If you test alert(originalRequest) you should also have
undefined.
For your trouble, what is the
On 09/17/2009 07:14 AM, david wrote:
Hi Jason,
the way you write it is good even in IE.
When write onComplete: parent_response() , you launch the function
at initialisation time, and the AJAX was not call, so you input is
undefined. If you test alert(originalRequest) you should also
Hi Mojito,
it seems to be a problem on float and it's accuracy.
If the resulted value must be exactly defined (0.3 and not
0.30004), then you should do a small calculation to set it to the
correct value :
value = parseInt(value*100,10) / 100
--
david
On 1 sep, 22:51, Mojito
I encountered this error in all versions of IE8 without non-alpha IDs.
After a lot of debugging and head scratching i discovered that if you
register an observer on the 'dom:load' event in a constructor
(initialize) thats supposed to fire one of the object methods (like
'this.recolour()') it will
Hi,
...if you
register an observer on the 'dom:load' event in a constructor
(initialize) thats supposed to fire one of the object methods (like
'this.recolour()') it will end up as an infinite loop in IE6, IE7 and
IE8...
Can you post a small, self-contained, complete example demonstrating
This will reproduce the issues sometimes (http://pastie.org/565352),
but it is not consistent. In principle its the same code that cause
the invalid handeler at line 4501, but it only produces the issue
occationaly. When running it causes a stack overflow at first, and
then produce the error at
On Jul 23, 12:28 pm, Jeff jtaylor...@gmail.com wrote:
We've having this exact error with IE8 and it's always related to
developers using element IDs that begin with non-Alpha characters.
Doing something like adding and underscore to the id fixes the
problem.
Note that an underscore is not
We've having this exact error with IE8 and it's always related to
developers using element IDs that begin with non-Alpha characters.
Doing something like adding and underscore to the id fixes the
problem.
On Jul 14, 6:37 am, adamski adam.elemen...@gmail.com wrote:
We're now going through the
Hi to evebody!
I'm getting the same error! Maybe you know the reason or how to fix
it But i guess it's a big of RC3.
Regards,
Dmitry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us
Hi adamski,
I use this version too, and have not this problem.
But What could you do?
if you have multiple js script, just supress all other script instead
prototype. if the error is still there, try download again prototype.
Otherwise, the problem could be in text encoding.
--
david
On 14
yes, target is hidden:
I'm using Autocompleter.selectbox (a scriptaculus plugin)
http://www.glanzani.com.ar/select/
I had to change Autocompleter behaviur to solve this issue, but I
preferred to solve the problem where it happens (as it's wrong how it
is calculated in ie8 the delta, not the fact
See
https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/618-getoffsetparent-returns-body-for-new-hidden-elements-in-ie8-final
I've posted an HTML example there that shows the difference between
shown and hidden elements.
I'm not sure what the real solution is to this.
-- Rod
Is your target element visible? I hit this same problem with IE8 in
our app for elements that were created with display:none;, IE8 seems
to think they don't have the right offsetParent. To fix, I simply made
them visible before calling clonePosition and the parent delta was
included correctly in
It might be new in the context of all versions of IE, but it can
hardly be a new bug in a browser that hasn't been released yet. ;-)
*Obviously* I meant new to the IE line. (And IE8 was released on
Thursday, although Microsoft's own Internet Explorer home page is a
bit divided about it...)
Hi Juriy,
Btw, as of today, all DOM tests fully pass on IE8.
T.J., do you mind giving it a spin?
On IE7, you mean? (I have only IE6 and IE7 systems right now.)
IE7 on Windows still has issues in form, dom, and selector tests with
the trunk (assuming git pull brings me up to date, I'm a git
On Mar 22, 4:42 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Juriy,
Btw, as of today, all DOM tests fully pass on IE8.
T.J., do you mind giving it a spin?
On IE7, you mean? (I have only IE6 and IE7 systems right now.)
I meant IE8 :)
IE7 on Windows still has issues in form,
Hi Juriy,
Thanks. I could reproduce this in IE6 and just pushed a
fixhttp://github.com/sstephenson/prototype/commit/2c986d8eaff47a6a181a1c...
It's fixed in IE7 as well, nice one!
-- T.J. :-)
On Mar 22, 3:04 pm, kangax kan...@gmail.com wrote:
On Mar 22, 4:42 am, T.J. Crowder
@masterleep:
I think there are still some IE8 issues. Now that a final is out,
they'll probably get resolved soon. I know kangax (at least) is
working on some of them and several have already been resolved in the
trunk version. Would you give the trunk version a go?
@RobG:
Then that is a
Hi All,
This appears to be a bug in IE, not prototype, as it is not applying
the class attribute using the specified 'className' property (http://
msdn.microsoft.com/en-us/library/ms533560(VS.85).aspx), but using the
attribute name 'class' instead, so as a work around I have added this
around
On Mar 21, 10:16 pm, Completely Free Dating - Andrew
andrewjdi...@gmail.com wrote:
Hi All,
This appears to be a bug in IE, not prototype, as it is not applying
the class attribute using the specified 'className' property (http://
msdn.microsoft.com/en-us/library/ms533560(VS.85).aspx), but
OK, I found this particular one... if you call
input_elem.readAttribute('value');
on an input element, and the value is equal to the empty string, then
in IE8 the result is null. On other browsers, the result is the empty
string.
On Mar 19, 11:47 am, masterleep bill-goo...@lipa.name wrote:
35 matches
Mail list logo
