Markus, we need to see a simple test case that demonstrates the
problem before we can do anything. If you see this again, please make
a simple HTML document that demonstrates the problem, and I'll do my
best to address it.
Thanks!
On 12-Mar-06, at 9:42 AM, [EMAIL PROTECTED] wrote:
Doug, thank you for the great test case. I'll get on this and let you
know what I can do.
On 21-Mar-06, at 2:38 PM, Doug Crawford wrote:
Here is simple test case that shows a leak in Drip 0.3 using the
latest
640 version of MochiKit. This is basically the same test case that I
Safari can't generate synthetic events and so always fails on these
tests. I should move them to the end of the suite, because Safari
stops processing tests on this failure.
Thank yoU!
On 18-Mar-06, at 3:11 PM, [EMAIL PROTECTED] wrote:
Anyway, while running these tests I got a failure:
Does anyone have a preference to Scriptalicious or YUI? Thomas, is
there anything I can help with?
On 17-Mar-06, at 4:28 AM, Kevin Dangoor wrote:
There's also the Scriptaculous port, which currently lives on a branch
in the repository..
I was looking into this today as well, but I think
OK, I'll have a look. I have a particular interest in the Drag and
Drop stuff, I'll concentrate my effort there. Do you want to keep
this as a strict Scriptalicious port, or do you mind pulling some
ideas from Dojo or YUI?
Does anyone have a preference to Scriptalicious or YUI?
Well, I
Yes, Signal should prevent IE memory leaks (if you use Signal.connect).
On 17-Mar-06, at 8:44 AM, Doug Crawford wrote:
As I understand it, if a DOM event handler closes over the element
triggering the event it will cause a memory leak in IE when the
page is
refreshed. Here is an example
I was looking into this today as well, but I think the YUI library
may be a better starting point.
On 16-Mar-06, at 5:52 PM, Leo wrote:
Is there a work in progress on making a drag drop extension to
Mochi?
I've rewritten chunks of DOM-Drag
(http://www.youngpup.net/2001/domdrag) to
The PEP 8 naming conventions suggest a single underscore indicates
weak internal use. Since JavaScript doesn't do name mangling,
should internal variables always use single instead of double
underscores? (Except special names like __repr__.)
In MochiKit.Signal.signal, I don't think it makes sense to run
through the slots and swallow errors if they occur and then just
throw a generic error when something breaks. It makes debugging suck,
and in production code, if something breaks, why not just let it
break? Can we remove the
Can't you just do a toUpperCase onblur? If you don't want to do that,
you could do something like this:
input id=upper type=text /
script
MochiKit.Signal.connect('upper', 'onkeyup',
function(e) {
var c = e.key().code;
if (65 = c c = 90) {
var u =
Right, but I think the soon part is important too. This:
code.js, line 73: Value undefined (result of expression e.blah) is
not object.
Is so much better than this:
Signal.js, line 472: There were errors in handling signal 'sig'.
I think you have a point. Maybe the error that wraps all
That would only ever throw the first exception.
Oops, of course. So is there a way to build a nicely formatted list
of errors, and throw that instead?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit
What's wrong with adding a property to the error-object ?
You need a debugger to see it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to
If this was a server-side framework in a language with better
facilities to report errors, then I might agree that the error
should
be logged and the next handler should continue. However, this is a
language with absolutely horrible error handling and it's client-
side
code.
It
Is there a mailinglist where you announce commits to the repository ?
No, but you can subscribe to an RSS feed in trac's timeline:
https://trac.mochibot.com/timeline
I think Bob meant:
http://trac.mochikit.com/timeline
--~--~-~--~~~---~--~~
You received this
OK, register_signals = registerSignals in trunk.
On 6-Mar-06, at 9:17 AM, Bob Ippolito wrote:
Hi. The wiki refers to PEP8 for naming-conventions, but I'm a bit
confused. It seems that global functions are named
lowercase_underscore, whereas memberfunctions (methods) as
studlyCaps.
This
That'd be me. Is this correct:
getViewportDimensions: function() {
var d = new MochiKit.DOM.Dimensions();
var self = MochiKit.DOM;
if (window.innerWidth) {
d.w = self._window.innerWidth;
d.h = self._window.innerHeight;
} else if
LayerX/Y and offsetX/Y are not equivalent. Here's a discussion about
this at Gecko's Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=122665#c3
To do something equivalent, I suggest you do something like this:
div id=containerThe container./div
var moveHandler = function(e) {
var
Does MochiKit have any cookie helpers? Cookies suck.
Sorry, I should have started with I think MochiKit should make
cookies not suck. I'm working with my first JS cookie today, and
it's horrible. Would they belong in .Base (with the JSON stuff)?
On 12-Feb-06, at 4:11 PM, Bob Ippolito wrote:
It'd be pretty easy to find if it did.. everything
Quick question: was IE in quirks mode when you did this?
On 31-Jan-06, at 1:17 PM, Bob Ippolito wrote:
MochiKit v1.3 [IE 7.0]
Type your expression in the input box below and press return, or
see the notes below for more information.
MochiKit.DOM.attributeArray.compliant
false
Do conditional comments work in .js files? I couldn't find any
reference to it, and tried:
/*[if IE]
alert('hello');
[endif]*/
That didn't work, and it doesn't seem to work with CSS either. In any
case, I don't think Dojo's compressor is the problem here.
On 31-Jan-06, at 11:42 AM, Bob
How's this:
setBox: function (elem, kind, box/* optional */, units) {
var newBox = {};
if (typeof(units) == 'undefined') {
units = 'px';
}
if (typeof(box) == 'number') {
newBox[kind + '-width'] = box + units;
} else {
MochiKit.Iter.forEach(box,
Instead of doing browser or object detects all over the MochiKit
code, how about moving all of the hacks to a separate include file
with all of the affected functions redefined, and ask people to
include it with a conditional comment? This would lean out the core,
speed things up a bit
What about asking users to do it in the head, like:
script src=MochiKit/MochiKit.js type=text/javascript/script
!--[if IE]script src=MochiKit/IE.js type=text/javascript/
script![endif]--
On 31-Jan-06, at 11:24 AM, Bob Ippolito wrote:
This would be a decent solution if Dojo's compressor
Thanks for checking this.
I added some Signal tests that fail to find cases where it wasn't
behaving as it should.
Signal Test Failures
Firefox: 25, 27
IE6: 7, 16, 17, 22, 23, 24, 25, 26, 27
Safari: 25, 27, (28 fails and because Safari doesn't support
synthetic
The bug here doesn't seem to be offsetWidth vs. clientWidth,
elementDimensions is doing this:
elem = self.getElement(elem);
if (self.computedStyle(elem, 'display') != 'none') {
return new self.Dimensions(elem.w || 0, elem.h || 0);
}
Since display != none, and elem.w and .h are
Thomas,
Thank you for the notes. I've made a few changes to the API I hope
you'll like:
1. I now return a MochiKit.Signal.Event object instead of mangling
the native event object. (The native event object is available as the
theParam.event property.)
2. I've changed the name of the
I think !== and === instead of cne and ce may work.
On 23-Jan-06, at 11:15 AM, Jonathan Gardner wrote:
My concern is that slots will get called twice. This is really bad
if you are
connecting a toggle type slot to a signal. You'd expect pressing
the button
to call it exactly once, but
This code should measure element position a bit more consistently
across browsers. Has anyone used this before?
// clientLeft and clientTop are defined only in IE, and are
// basically equivalent to border:
// http://msdn.microsoft.com/workshop/author/om/measuring.asp
x += elem.offsetLeft +
And for all the Safari users out there, this tool lets you execute
arbitrary JavaScript against the front-most Safari window:
http://safariguide.net/
On 20-Jan-06, at 5:08 PM, Thomas Winningham wrote:
Good tip is for you to include your own JS source on the interpreter
demo, and edit that
So events are driving me nuts. Normalization is difficult because
some browsers get their backs up when you mess with something like
event.button, or event.timeStamp. The Level 2 DOM spec is incomplete
and in some cases wrong-headed (event.button, for instance). Mozilla
still has some
I've tried to adopt and extend Dojo's event normalization scheme for
MochiKit.Signal. I also changed MochiKit.Signal to use W3C-style
event names like keyup instead of onkeyup.
With these changes, you should end up with a consistent way to access
the event object in Safari, IE, Firefox,
JavaScript does have an in operator.
The in operator expects a lefthand operand that is or can be
converted to a string. It expects a righthand operand that is an
object (or array). It evaluates to true if the lefthand value is the
name of a property of the righthand object. For example:
101 - 134 of 134 matches
Mail list logo
