23242 0 true 2009-08-02T12:19:37+01:00 47481 41986 102 slider-wont-initialize-correctly-inside-hidden-div-fix-inside 18 24057 resolved 2009-12-22T07:14:03+00:00 80497 tozyx ieowqw (at gmail) Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/102 1.2.4.1 I've run into a problem where, in my situation, I have a slider in a hidden div which becomes visible when an "advanced options" button is clicked. It starts off as display: none and becomes display: block. Because of the way the slider plugin initialises, it doesn't measure the element and knob correctly, and thinks the slider is 0px wide. This is because it is measuring with offsetWidth and offsetHeight, which doesn't work on hidden elements. I've made a small change to my mootools-more to address this, and thought I'd share it with everyone. I've changed the following code inside initialize: switch (this.options.mode){ case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'offsetHeight'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'offsetWidth'; } this.half = this.knob[offset] / 2; this.full = this.element[offset] - this.knob[offset] + (this.options.offset * 2); into switch (this.options.mode){ case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'height'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'width'; } /* Fix for initializing a slider when the element is hidden */ var elementDimensions = this.element.measure(function() { return this.getDimensions(); }); var knobDimensions = this.knob.measure(function() { return this.getDimensions(); }); this.half = knobDimensions[offset] / 2; this.full = elementDimensions[offset] - knobDimensions[offset] + (this.options.offset * 2); This measures the items in a more reliable way. I've run into a problem where, in my situation, I have a slider in a hidden div which becomes visible when an "advanced options" button is clicked. It starts off as display: none and becomes display: block. Because of the way the slider plugin initialises, it doesn't measure the element and knob correctly, and thinks the slider is 0px wide. This is because it is measuring with offsetWidth and offsetHeight, which doesn't work on hidden elements. I've made a small change to my mootools-more to address this, and thought I'd share it with everyone. I've changed the following code inside initialize: switch (this.options.mode){ case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'offsetHeight'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'offsetWidth'; } this.half = this.knob[offset] / 2; this.full = this.element[offset] - this.knob[offset] + (this.options.offset * 2); into switch (this.options.mode){ case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'height'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'width'; } /* Fix for initializing a slider when the element is hidden */ var elementDimensions = this.element.measure(function() { return this.getDimensions(); }); var knobDimensions = this.knob.measure(function() { return this.getDimensions(); }); this.half = knobDimensions[offset] / 2; this.full = elementDimensions[offset] - knobDimensions[offset] + (this.options.offset * 2); This measures the items in a more reliable way. <div><p>I've run into a problem where, in my situation, I have a slider in a hidden div which becomes visible when an "advanced options" button is clicked. It starts off as display: none and becomes display: block.</p> <p>Because of the way the slider plugin initialises, it doesn't measure the element and knob correctly, and thinks the slider is 0px wide. This is because it is measuring with offsetWidth and offsetHeight, which doesn't work on hidden elements.</p> <p>I've made a small change to my mootools-more to address this, and thought I'd share it with everyone. I've changed the following code inside initialize:</p> <p>switch (this.options.mode){</p> <pre> <code>case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'offsetHeight'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'offsetWidth'; </code> </pre> <p>}</p> <p>this.half = this.knob[offset] / 2; this.full = this.element[offset] - this.knob[offset] + (this.options.offset * 2);</p> <p>into</p> <p>switch (this.options.mode){</p> <pre> <code>case 'vertical': this.axis = 'y'; this.property = 'top'; offset = 'height'; break; case 'horizontal': this.axis = 'x'; this.property = 'left'; offset = 'width'; </code> </pre> <p>}</p> <p>/ <em>Fix for initializing a slider when the element is hidden</em> / var elementDimensions = this.element.measure(function() { return this.getDimensions(); }); var knobDimensions = this.knob.measure(function() { return this.getDimensions(); }); this.half = knobDimensions[offset] / 2; this.full = elementDimensions[offset] - knobDimensions[offset] + (this.options.offset * 2);</p> <p>This measures the items in a more reliable way.</p></div> 0 true 2009-06-05T13:02:03+01:00 58195 41986 68 improving-elementpin-for-ie6 3 24057 wontfix fix more morph pin 2009-11-06T08:40:26+00:00 58195 kizu (at web-standards) kizu (at web-standards) http://mootools.lighthouseapp.com/projects/24057/tickets/68 1.2.4.1 There is a way to minimize the "jittery" of pinned block in IE6 — if you have a background on a HTML or BODY element and it's background-attachment property is set to "fixed" the pinned element almost stops to jitter, in a magical way :) I created a test case — http://dl.getdropbox.com/u/1077344/Projects/kizu/research/mootools.pin/index.html At start the pinned element is pinned as always, but after clicking on a button in IE it's behavior becomes somewhat "fixed" :) I think we can add some rules in a else block where we check for supportsPositionFixed, and then check if there is no background-image on HTML or BODY and then set one of them to { background-image:url(about:blank); background-attachment:fixed; } There is a way to minimize the "jittery" of pinned block in IE6 — if you have a background on a HTML or BODY element and it's background-attachment property is set to "fixed" the pinned element almost stops to jitter, in a magical way :) I created a test case — http://dl.getdropbox.com/u/1077344/Projects/kizu/research/mootools.pin/index.html At start the pinned element is pinned as always, but after clicking on a button in IE it's behavior becomes somewhat "fixed" :) I think we can add some rules in a else block where we check for supportsPositionFixed, and then check if there is no background-image on HTML or BODY and then set one of them to { background-image:url(about:blank); background-attachment:fixed; } <div><p>There is a way to minimize the "jittery" of pinned block in IE6 &#8212; if you have a background on a HTML or BODY element and it's background-attachment property is set to "fixed" the pinned element almost stops to jitter, in a magical way :)</p> <p>I created a test case &#8212; <a href="http://dl.getdropbox.com/u/1077344/Projects/kizu/research/mootools.pin/index.html"> http://dl.getdropbox.com/u/10773...</a></p> <p>At start the pinned element is pinned as always, but after clicking on a button in IE it's behavior becomes somewhat "fixed" :)</p> <p>I think we can add some rules in a else block where we check for supportsPositionFixed, and then check if there is no background-image on HTML or BODY and then set one of them to {</p> <pre> <code>background-image:url(about:blank); background-attachment:fixed; </code> </pre> <p>}</p></div> 23242 0 true 2009-06-17T08:58:39+01:00 60270 41986 75 form-validator-should-ignore-disabled-fields 23 24057 resolved formvalidator 2009-10-09T01:21:18+01:00 23242 Aaron Newton storeman Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/75 1.2.4.1 I think the form validator ['required'] should ignore disabled fields, these aren't even submitted by the browser, so they can't do any damage. @@@javascript ['required', { errorMsg: function(){ return FormValidator.getMsg('required'); }, test: function(element){ return element.get('disabled') || !FormValidator.getValidator('IsEmpty').test(element); } }], @@@ I think the form validator ['required'] should ignore disabled fields, these aren't even submitted by the browser, so they can't do any damage. @@@javascript ['required', { errorMsg: function(){ return FormValidator.getMsg('required'); }, test: function(element){ return element.get('disabled') || !FormValidator.getValidator('IsEmpty').test(element); } }], @@@ <div><p>I think the form validator ['required'] should ignore disabled fields, these aren't even submitted by the browser, so they can't do any damage.</p> <p>@@@javascript ['required', {</p> <pre> <code> errorMsg: function(){ return FormValidator.getMsg('required'); }, test: function(element){ return element.get('disabled') || !FormValidator.getValidator('IsEmpty').test(element); } }], </code> </pre> <pre><code> </code></pre></div> 23242 0 true 2009-07-01T20:26:53+01:00 61567 41986 82 formvalidator-documentation-not-up-to-date 22 24057 resolved formvalidator formvalidator.inline 2009-10-09T01:10:31+01:00 23242 Aaron Newton wontoner Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/82 1.2.4.1 While reading over the documentation at: http://mootools.net/docs/more/Forms/FormValidator I saw the instructions "You can define a css class-name value called msgPos as the id of an element into which the validation errors for that input will be inserted.." Which are not currently applicable to FormValidator, but FormValidator.Inline If you could update those docs it may save some ppl time. Also, on: http://mootools.net/docs/more/Forms/FormValidator.Inline You have the syntax 'new FormValidator(form[, options]);' but it should be 'new FormValidator.Inline(form[, options]);' While reading over the documentation at: http://mootools.net/docs/more/Forms/FormValidator I saw the instructions "You can define a css class-name value called msgPos as the id of an element into which the validation errors for that input will be inserted.." Which are not currently applicable to FormValidator, but FormValidator.Inline If you could update those docs it may save some ppl time. Also, on: http://mootools.net/docs/more/Forms/FormValidator.Inline You have the syntax 'new FormValidator(form[, options]);' but it should be 'new FormValidator.Inline(form[, options]);' <div><p>While reading over the documentation at:</p> <p><a href="http://mootools.net/docs/more/Forms/FormValidator">http://mootools.net/docs/more/Fo...</a></p> <p>I saw the instructions "You can define a css class-name value called msgPos as the id of an element into which the validation errors for that input will be inserted.." Which are not currently applicable to FormValidator, but FormValidator.Inline</p> <p>If you could update those docs it may save some ppl time.</p> <p>Also, on:</p> <p><a href="http://mootools.net/docs/more/Forms/FormValidator.Inline">http://mootools.net/docs/more/Fo...</a></p> <p>You have the syntax 'new FormValidator(form[, options]);' but it should be 'new FormValidator.Inline(form[, options]);'</p></div> 23242 0 true 2009-07-03T12:49:29+01:00 61763 41986 84 website-documentation-error 21 24057 resolved documentation 2009-10-09T01:08:14+01:00 23242 Aaron Newton woomla Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/84 1.2.4.1 Hi, Occasionally I see a documentation error. Can I post it here? In this case: http://www.mootools.net/docs/more/Native/URI URI Method get valid parts misses 'user' and 'password' and 'path' should be 'file'. Hi, Occasionally I see a documentation error. Can I post it here? In this case: http://www.mootools.net/docs/more/Native/URI URI Method get valid parts misses 'user' and 'password' and 'path' should be 'file'. <div><p>Hi,</p> <p>Occasionally I see a documentation error. Can I post it here?</p> <p>In this case:</p> <p><a href="http://www.mootools.net/docs/more/Native/URI">http://www.mootools.net/docs/mor...</a> URI Method get</p> <pre> <code>valid parts </code> </pre> <p>misses 'user' and 'password' and 'path' should be 'file'.</p></div> 23242 0 true 2009-07-14T22:28:22+01:00 53118 41986 92 tips-improvements-fixes 20 24057 resolved 2009-10-09T01:03:03+01:00 23242 Aaron Newton Thomas Allmer Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/92 1.2.4.1 added className 'tip-wrap' by default as you could use it fire an Event during the attachment of an element so you could start with a fade out element [otherwise the tooltip will pop up the first time as it can't find an value to tween from] remove the display: none in elementLeave as it prevents you from fading a tooltip out I sent you an pull request (1ed98b1) added className 'tip-wrap' by default as you could use it fire an Event during the attachment of an element so you could start with a fade out element [otherwise the tooltip will pop up the first time as it can't find an value to tween from] remove the display: none in elementLeave as it prevents you from fading a tooltip out I sent you an pull request (1ed98b1) <div><p>added className 'tip-wrap' by default as you could use it fire an Event during the attachment of an element so you could start with a fade out element [otherwise the tooltip will pop up the first time as it can't find an value to tween from] remove the display: none in elementLeave as it prevents you from fading a tooltip out</p> <p>I sent you an pull request (1ed98b1)</p></div> 23242 0 true 2009-09-04T15:23:12+01:00 61691 41986 116 need-an-event-to-fire-on-queue-endcomplete 15 24057 resolved request.queue 2009-10-08T23:24:58+01:00 23242 Aaron Newton Ray Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/116 1.2.4.1 Need an event that fires when the queue is completed all requests and after their own event handlers. onRequestComplete appears to fire with every request's complete, but before the requests own onComplete. onRequestEnd doesn't appear to fire. I have a form that has a field onBlur(grab ajax data, onComplete(update totals)), and users updating the data in the field, blurs by clicking submit, which submits the form before the ajax onComplete() Need an event that fires when the queue is completed all requests and after their own event handlers. onRequestComplete appears to fire with every request's complete, but before the requests own onComplete. onRequestEnd doesn't appear to fire. I have a form that has a field onBlur(grab ajax data, onComplete(update totals)), and users updating the data in the field, blurs by clicking submit, which submits the form before the ajax onComplete() <div><p>Need an event that fires when the queue is completed all requests and after their own event handlers.</p> <p>onRequestComplete appears to fire with every request's complete, but before the requests own onComplete.<br> onRequestEnd doesn't appear to fire.</p> <p>I have a form that has a field onBlur(grab ajax data, onComplete(update totals)), and users updating the data in the field, blurs by clicking submit, which submits the form before the ajax onComplete()</p></div> 28477 1 true 2009-07-25T01:26:42+01:00 63965 41986 96 type-in-dutch-datelang-august-month-name 3 24057 resolved 1.2.3.2 date moolang typo 2009-10-08T17:16:59+01:00 28477 Scott Kyle KoenWilliame Scott Kyle http://mootools.lighthouseapp.com/projects/24057/tickets/96 1.2.4.1 augustus is spelled augustys In attachment the patch... augustus is spelled augustys In attachment the patch... <div><p>augustus is spelled augustys</p> <p>In attachment the patch...</p></div> 23242 0 true 2009-07-29T10:51:53+01:00 39002 41986 98 requestqueue-documentation-inconsistencies 19 24057 resolved 2009-10-08T06:59:23+01:00 23242 Aaron Newton Jasper Smet Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/98 1.2.4.1 Hi, Just wanted to let you guys know that the callback methods described in the documentation of Request.Queue or not consistent with the actual code: callbacks in documentation : * onRequestStart * onRequestEnd * onRequestSuccess * onRequestComplete * onRequestCancel * onRequestException * onRequestFailure callbacks in actual code (at http://github.com/mootools/mootools-more/blob/66f6742d1f0859c2903a06e641091966cc756b68/Source/Request/Request.Queue.js) * onRequest * onSuccess * onComplete * onCancel * onException * onFailure Can someone please adjust this in the documentation to prevent confusion? I spent some time figuring out why this didn't work in an adobe air application i am building. Thanks and keep up the great work!! Hi, Just wanted to let you guys know that the callback methods described in the documentation of Request.Queue or not consistent with the actual code: callbacks in documentation : * onRequestStart * onRequestEnd * onRequestSuccess * onRequestComplete * onRequestCancel * onRequestException * onRequestFailure callbacks in actual code (at http://github.com/mootools/mootools-more/blob/66f6742d1f0859c2903a06e641091966cc756b68/Source/Request/Request.Queue.js) * onRequest * onSuccess * onComplete * onCancel * onException * onFailure Can someone please adjust this in the documentation to prevent confusion? I spent some time figuring out why this didn't work in an adobe air application i am building. Thanks and keep up the great work!! <div><p>Hi,</p> <p>Just wanted to let you guys know that the callback methods described in the documentation of Request.Queue or not consistent with the actual code:</p> <p>callbacks in documentation :</p> <pre> <code>* onRequestStart * onRequestEnd * onRequestSuccess * onRequestComplete * onRequestCancel * onRequestException * onRequestFailure </code> </pre> <p>callbacks in actual code (at <a href="http://github.com/mootools/mootools-more/blob/66f6742d1f0859c2903a06e641091966cc756b68/Source/Request/Request.Queue.js)"> http://github.com/mootools/mooto...</a></p> <pre> <code>* onRequest * onSuccess * onComplete * onCancel * onException * onFailure </code> </pre> <p>Can someone please adjust this in the documentation to prevent confusion? I spent some time figuring out why this didn't work in an adobe air application i am building.</p> <p>Thanks and keep up the great work!!</p></div> 23242 0 true 2009-08-07T10:12:06+01:00 23031 41986 104 documentation-correction-in-fxfxaccordion 17 24057 resolved 2009-10-08T06:53:51+01:00 23242 Aaron Newton Jaik Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/104 1.2.4.1 The documentation states: # fixedHeight - (boolean: defaults to false) If set to true, displayed elements will have a fixed height. # fixedWidth - (boolean: defaults to false) If set to true, displayed elements will have a fixed width. However, the code actually accepts a height and width value for these arguments, or a boolean false, but not a boolean true. The documentation states: # fixedHeight - (boolean: defaults to false) If set to true, displayed elements will have a fixed height. # fixedWidth - (boolean: defaults to false) If set to true, displayed elements will have a fixed width. However, the code actually accepts a height and width value for these arguments, or a boolean false, but not a boolean true. <div><p>The documentation states:</p> <h1>fixedHeight - (boolean: defaults to false) If set to true, displayed elements will have a fixed height.</h1> <h1>fixedWidth - (boolean: defaults to false) If set to true, displayed elements will have a fixed width.</h1> <p>However, the code actually accepts a height and width value for these arguments, or a boolean false, but not a boolean true.</p></div> 23242 0 true 2009-07-25T22:18:24+01:00 22206 41986 97 when-elementdissolve-is-called-before-a-reveal-fx-is-finished-the-element-gets-hidden-and-wont-show-on-reveal 16 24057 resolved fx reveal snap 2009-10-08T05:53:14+01:00 23242 Aaron Newton elado Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/97 1.2.4.1 A code sample: @@@ javascript <script type="text/javascript"> window.addEvent("domready",function () { var x=$("x"); $("reveal").addEvent("click",function (e) { e.stop(); x.reveal(); }); $("dissolve").addEvent("click",function (e) { e.stop(); x.dissolve(); }); }) </script> <button type="button" id="reveal">reveal</button> <button type="button" id="dissolve">dissolve</button> <div id="x" style="display:none;border:1px solid #000;"> open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/> </div> @@@ When "reveal" is clicked and before the fx is finished, "dissolve" is clicked, the element gets hidden and clicking "reveal" again doesn't work. A code sample: @@@ javascript <script type="text/javascript"> window.addEvent("domready",function () { var x=$("x"); $("reveal").addEvent("click",function (e) { e.stop(); x.reveal(); }); $("dissolve").addEvent("click",function (e) { e.stop(); x.dissolve(); }); }) </script> <button type="button" id="reveal">reveal</button> <button type="button" id="dissolve">dissolve</button> <div id="x" style="display:none;border:1px solid #000;"> open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/>open<br/> </div> @@@ When "reveal" is clicked and before the fx is finished, "dissolve" is clicked, the element gets hidden and clicking "reveal" again doesn't work. <div><p>A code sample:</p> <pre><code class="javascript"> &lt;script type=&quot;text/javascript&quot;&gt; window.addEvent(&quot;domready&quot;,function () { var x=$(&quot;x&quot;); $(&quot;reveal&quot;).addEvent(&quot;click&quot;,function (e) { e.stop(); x.reveal(); }); $(&quot;dissolve&quot;).addEvent(&quot;click&quot;,function (e) { e.stop(); x.dissolve(); }); }) &lt;/script&gt; &lt;button type=&quot;button&quot; id=&quot;reveal&quot;&gt;reveal&lt;/button&gt; &lt;button type=&quot;button&quot; id=&quot;dissolve&quot;&gt;dissolve&lt;/button&gt; &lt;div id=&quot;x&quot; style=&quot;display:none;border:1px solid #000;&quot;&gt; open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt;open&lt;br/&gt; &lt;/div&gt; </code></pre> <p>When "reveal" is clicked and before the fx is finished, "dissolve" is clicked, the element gets hidden and clicking "reveal" again doesn't work.</p></div> 23242 0 true 2009-09-10T14:50:04+01:00 69276 41986 117 slider-only-click-on-the-knob 5 24057 resolved clickelement slider 2009-10-08T01:52:12+01:00 23242 Aaron Newton sargerasy Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/117 1.2.4.1 Use slider, when you only click at the knob element and not move it,release mouse button, then you click other place, the clickElement function will not work correctly. My solution: Add a onCancel function in dragOptions, make isDragging false. Use slider, when you only click at the knob element and not move it,release mouse button, then you click other place, the clickElement function will not work correctly. My solution: Add a onCancel function in dragOptions, make isDragging false. <div><p>Use slider, when you only click at the knob element and not move it,release mouse button, then you click other place, the clickElement function will not work correctly.<br> My solution: Add a onCancel function in dragOptions, make isDragging false.</p></div> 23242 0 true 2009-07-30T02:04:08+01:00 21410 41986 99 elementinsertatcursor-ie7-and-newlines 14 24057 resolved element more "text range" 2009-10-08T01:51:18+01:00 23242 Aaron Newton Artnez Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/99 1.2.4.1 Very simple to recreate the problem: 1) Start with a blank <textarea> 2) Type a few characters into the textarea 3) Create a few newlines (hit enter a few times) 4) Try insertAtCursor() IE ignores the trailing newlines and inserts your text just after the text you created in Step 2 above. After testing things out it seems that when you do [text range].text.length, IE ignores trailing newlines. Very simple to recreate the problem: 1) Start with a blank <textarea> 2) Type a few characters into the textarea 3) Create a few newlines (hit enter a few times) 4) Try insertAtCursor() IE ignores the trailing newlines and inserts your text just after the text you created in Step 2 above. After testing things out it seems that when you do [text range].text.length, IE ignores trailing newlines. <div><p>Very simple to recreate the problem: 1) Start with a blank 2) Type a few characters into the textarea 3) Create a few newlines (hit enter a few times) 4) Try insertAtCursor()</p> <p>IE ignores the trailing newlines and inserts your text just after the text you created in Step 2 above.</p> <p>After testing things out it seems that when you do [text range].text.length, IE ignores trailing newlines.</p></div> 23242 0 true 2009-09-24T02:13:23+01:00 55058 41986 127 overtext-tips-hook-onto-dom-change 13 24057 resolved 2009-10-08T01:50:44+01:00 23242 Aaron Newton Varyen Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/127 1.2.4.1 23242 0 true 2009-07-22T13:32:19+01:00 63297 41986 94 fxsortswap-not-chainable-in-mootools-more-1231 12 24057 resolved fx sort 2009-10-08T01:35:02+01:00 23242 Aaron Newton Tommy Valand Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/94 1.2.4.1 The last line of the swap-method is like this: this.sort(newOrder); Should be this: return this.sort(newOrder); The last line of the swap-method is like this: this.sort(newOrder); Should be this: return this.sort(newOrder); <div><p>The last line of the swap-method is like this: this.sort(newOrder);</p> <p>Should be this: return this.sort(newOrder);</p></div> 23242 0 true 2009-09-18T11:26:33+01:00 63297 41986 122 bug-in-formvalidator-when-ignorehiddentrue 11 24057 resolved formvalidator ignorehidden 2009-10-08T01:30:54+01:00 23242 Aaron Newton Tommy Valand Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/122 1.2.4.1 The original code doesn't fire the elementValidate field if the field is hidden, but it still validates it. The result is that the form doesn't submit if a hidden field is invalid, regardless of the igonreHidden option. Original code: @@@ javascript test: function(className, field, warn){ var validator = this.getValidator(className); field = document.id(field); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator && this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid; }, isVisible : function(field){ if (!this.options.ignoreHidden) return true; while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true; } @@@ Suggested change: Move the ignoreHidden-check to the test-method, and do the test at the top of this. @@@ javascript test: function(className, field, warn){ field = document.id(field); if(this.options.ignoreHidden && !this.isVisible(field) ){ return true; } var validator = this.getValidator(className); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator && this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid; }, isVisible : function(field){ while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true; } @@@ The original code doesn't fire the elementValidate field if the field is hidden, but it still validates it. The result is that the form doesn't submit if a hidden field is invalid, regardless of the igonreHidden option. Original code: @@@ javascript test: function(className, field, warn){ var validator = this.getValidator(className); field = document.id(field); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator && this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid; }, isVisible : function(field){ if (!this.options.ignoreHidden) return true; while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true; } @@@ Suggested change: Move the ignoreHidden-check to the test-method, and do the test at the top of this. @@@ javascript test: function(className, field, warn){ field = document.id(field); if(this.options.ignoreHidden && !this.isVisible(field) ){ return true; } var validator = this.getValidator(className); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator && this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid; }, isVisible : function(field){ while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true; } @@@ <div><p>The original code doesn't fire the elementValidate field if the field is hidden, but it still validates it. The result is that the form doesn't submit if a hidden field is invalid, regardless of the igonreHidden option.</p> <p>Original code:<br></p> <pre> <code class= "javascript">test: function(className, field, warn){<br> <br> </code> </pre> <pre> <code class= "javascript"><code>var validator = this.getValidator(className); field = document.id(field); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator &amp;amp;&amp;amp; this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid;</code></code> </pre> <pre> <br> }, isVisible : function(field){ </pre> <pre> <code>if (!this.options.ignoreHidden) return true; while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true;</code> </pre> <pre> <br> } </pre> <p>Suggested change:<br> Move the ignoreHidden-check to the test-method, and do the test at the top of this.</p> <pre> <code class="javascript">test: function(className, field, warn){ field = document.id(field); if(this.options.ignoreHidden &amp;&amp; !this.isVisible(field) ){ return true; } var validator = this.getValidator(className); if (field.hasClass('ignoreValidation')) return true; warn = $pick(warn, false); if (field.hasClass('warnOnly')) warn = true; var isValid = validator ? validator.test(field) : true; if (validator &amp;&amp; this.isVisible(field)) this.fireEvent('elementValidate', [isValid, field, className, warn]); if (warn) return true; return isValid; }, isVisible : function(field){ while(field != document.body){ if (document.id(field).getStyle('display') == 'none') return false; field = field.getParent(); } return true; }</code> </pre></div> 23242 0 true 2009-09-21T08:22:20+01:00 70442 41986 123 tips-nesting-bug 10 24057 resolved 2009-10-08T01:28:06+01:00 23242 Aaron Newton Coen Hyde Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/123 1.2.4.1 There is a slight bug when an element with a tip is nested inside another element that also has a tip. When the mouse exits the nested element the tip from the parent fails to reappear. Here is a quick hack i did to solve the problem. var TipsExtended = new Class({ Extends: Tips, elementLeave: function(event, element){ this.parent(event, element); if (parentNode = this.parentHasTooltip(element)) { parentNode.fireEvent('mouseenter', event); } }, parentHasTooltip: function(element) { parentNode = element.getParent(); if (parentNode.retrieve('tip:enter')) return parentNode; if (parentNode.get('tag') == 'body') return false; else return this.parentHasTooltip(parentNode); } }); There is a slight bug when an element with a tip is nested inside another element that also has a tip. When the mouse exits the nested element the tip from the parent fails to reappear. Here is a quick hack i did to solve the problem. var TipsExtended = new Class({ Extends: Tips, elementLeave: function(event, element){ this.parent(event, element); if (parentNode = this.parentHasTooltip(element)) { parentNode.fireEvent('mouseenter', event); } }, parentHasTooltip: function(element) { parentNode = element.getParent(); if (parentNode.retrieve('tip:enter')) return parentNode; if (parentNode.get('tag') == 'body') return false; else return this.parentHasTooltip(parentNode); } }); <div><p>There is a slight bug when an element with a tip is nested inside another element that also has a tip. When the mouse exits the nested element the tip from the parent fails to reappear. Here is a quick hack i did to solve the problem.</p> <p>var TipsExtended = new Class({<br></p> <pre> <code>Extends: Tips, elementLeave: function(event, element){ this.parent(event, element); if (parentNode = this.parentHasTooltip(element)) { parentNode.fireEvent('mouseenter', event); } }, parentHasTooltip: function(element) { parentNode = element.getParent(); if (parentNode.retrieve('tip:enter')) return parentNode; if (parentNode.get('tag') == 'body') return false; else return this.parentHasTooltip(parentNode); }</code> </pre> <p>});</p></div> 23242 0 true 2009-09-24T01:09:09+01:00 55058 41986 126 overtext-should-set-focus-on-input-after-clicking 9 24057 resolved usability 2009-10-08T01:12:09+01:00 23242 Aaron Newton Varyen Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/126 1.2.4.1 Hi, I think you should focus on input after clicking on tip, assigned to input by overtext. When i click on input i want to start typing or paste something into it, but i can't do it without one extra clicking :). This is applicable only if you click right on tip. focus: function(){ if (!this.text.isDisplayed() || this.element.get('disabled')) return; this.hide(); this.element.focus(); // just add something like that }, Tested in FF 3.5, Chrome. Hi, I think you should focus on input after clicking on tip, assigned to input by overtext. When i click on input i want to start typing or paste something into it, but i can't do it without one extra clicking :). This is applicable only if you click right on tip. focus: function(){ if (!this.text.isDisplayed() || this.element.get('disabled')) return; this.hide(); this.element.focus(); // just add something like that }, Tested in FF 3.5, Chrome. <div><p>Hi,</p> <p>I think you should focus on input after clicking on tip, assigned to input by overtext. When i click on input i want to start typing or paste something into it, but i can't do it without one extra clicking :).</p> <p>This is applicable only if you click right on tip.</p> <pre> <code>focus: function(){ if (!this.text.isDisplayed() || this.element.get('disabled')) return; this.hide(); this.element.focus(); // just add something like that },</code> </pre> <p>Tested in FF 3.5, Chrome.</p></div> 23242 0 true 2009-09-25T11:24:07+01:00 48624 41986 131 classocclude-shortcut-not-as-described-in-docs 8 24057 resolved 2009-10-08T00:58:12+01:00 23242 Aaron Newton Robb3h Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/131 1.2.4.1 Hi there, Not sure if it's the documentation or the functionality which is wrong but the mootools docs say: "In the example above, because we have a toElement method and because we define the property property in the class, the method occlude doesn't require any arguments as it uses these by default." While in reality the toElement function doesn't appear to be used, as the code in Class.Occlude checks for the element with: element = document.id(element || this.element); and so using toElement does not allow you to use the shortcut. The clientcide example is correct however. Hi there, Not sure if it's the documentation or the functionality which is wrong but the mootools docs say: "In the example above, because we have a toElement method and because we define the property property in the class, the method occlude doesn't require any arguments as it uses these by default." While in reality the toElement function doesn't appear to be used, as the code in Class.Occlude checks for the element with: element = document.id(element || this.element); and so using toElement does not allow you to use the shortcut. The clientcide example is correct however. <div><p>Hi there,</p> <p>Not sure if it's the documentation or the functionality which is wrong but the mootools docs say:</p> <p>"In the example above, because we have a toElement method and because we define the property property in the class, the method occlude doesn't require any arguments as it uses these by default."</p> <p>While in reality the toElement function doesn't appear to be used, as the code in Class.Occlude checks for the element with:</p> <p>element = document.id(element || this.element);</p> <p>and so using toElement does not allow you to use the shortcut. The clientcide example is correct however.</p></div> 23242 0 true 2009-10-03T00:36:29+01:00 22512 41986 133 assetjavascript-documention 7 24057 resolved documentation 2009-10-08T00:56:03+01:00 23242 Aaron Newton batman42ca Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/133 1.2.4.1 The documentation for Asset.javascript() doesn't show that there is an onload() event The documentation for Asset.javascript() doesn't show that there is an onload() event <div><p>The documentation for Asset.javascript() doesn't show that there is an onload() event</p></div> 23242 0 true 2009-09-24T07:15:59+01:00 29571 41986 128 sliders-fail-when-initialized-under-various-display-property-use-cases 6 24057 resolved display measure offsetwidth slider 2009-10-08T00:50:47+01:00 23242 Aaron Newton csuwldcat Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/128 1.2.4.1 Basically if you are using Fx.Reveal or any other mechanism that sets either the slider element or its parent element to display: none; and try to init a slider, you end up with a non-working slider that throws no errors. It sticks at 0 because the slider script in More measures the offsetWidth on a display none element thus it thinks the slider is 0px wide. Needless to say NaN hilariousity ensues and you find yourself wanting to stab yourself in the eye with a rusty nail, jk...but seriously, it sucks. I would assume the script should be coded to use the measure More plugin so that it can actually derive a height. If that isn't clear just give me a holler. BTW, still cant upload my test pages with "attach a file" - so that is why i keep just writing this stuff out ;) Basically if you are using Fx.Reveal or any other mechanism that sets either the slider element or its parent element to display: none; and try to init a slider, you end up with a non-working slider that throws no errors. It sticks at 0 because the slider script in More measures the offsetWidth on a display none element thus it thinks the slider is 0px wide. Needless to say NaN hilariousity ensues and you find yourself wanting to stab yourself in the eye with a rusty nail, jk...but seriously, it sucks. I would assume the script should be coded to use the measure More plugin so that it can actually derive a height. If that isn't clear just give me a holler. BTW, still cant upload my test pages with "attach a file" - so that is why i keep just writing this stuff out ;) <div><p>Basically if you are using Fx.Reveal or any other mechanism that sets either the slider element or its parent element to display: none; and try to init a slider, you end up with a non-working slider that throws no errors. It sticks at 0 because the slider script in More measures the offsetWidth on a display none element thus it thinks the slider is 0px wide.</p> <p>Needless to say NaN hilariousity ensues and you find yourself wanting to stab yourself in the eye with a rusty nail, jk...but seriously, it sucks.</p> <p>I would assume the script should be coded to use the measure More plugin so that it can actually derive a height.</p> <p>If that isn't clear just give me a holler.</p> <p>BTW, still cant upload my test pages with "attach a file" - so that is why i keep just writing this stuff out ;)</p></div> 28477 0 true 2009-09-24T23:20:45+01:00 22895 41986 130 docs-element-elementshortcuts-swapclass 1 24057 resolved documentation element more shortcuts swapclass 2009-09-25T08:38:41+01:00 28477 Scott Kyle dEEf Scott Kyle http://mootools.lighthouseapp.com/projects/24057/tickets/130 1.2.4.1 mootools-more / Docs / Element / Element.Shortcuts The documentation of the swapClass method is reverse to the actual method. mootools-more / Docs / Element / Element.Shortcuts The documentation of the swapClass method is reverse to the actual method. <div><p>mootools-more / Docs / Element / Element.Shortcuts</p> <p>The documentation of the swapClass method is reverse to the actual method.</p></div> 3 true 2009-06-08T16:06:32+01:00 35838 41986 70 sortable-slow-on-firefox-on-linux 1 24057 wontfix performace sortable 2009-09-14T07:32:37+01:00 23242 Aaron Newton Declan Conlon http://mootools.lighthouseapp.com/projects/24057/tickets/70 1.2.4.1 Mootools version: Latest from website, included as attachment. I'm having some trouble with sortables on FF, performance-wise that is. For the attached test case I'm seeing horrible laggy behaviour. It works perfectly in webkit browsers and IE7. While not exhaustive I've tried it in a number of FF versions and all are prone to the laggy behaviour, including 3.5 betas. Attached is a test case and a screenshot of a firebug profile showing the dominating functions(may or may not help). It looks like mootools is doing a lot of work, perhaps it can be optimised. Mootools version: Latest from website, included as attachment. I'm having some trouble with sortables on FF, performance-wise that is. For the attached test case I'm seeing horrible laggy behaviour. It works perfectly in webkit browsers and IE7. While not exhaustive I've tried it in a number of FF versions and all are prone to the laggy behaviour, including 3.5 betas. Attached is a test case and a screenshot of a firebug profile showing the dominating functions(may or may not help). It looks like mootools is doing a lot of work, perhaps it can be optimised. <div><p>Mootools version: Latest from website, included as attachment.</p> <p>I'm having some trouble with sortables on FF, performance-wise that is. For the attached test case I'm seeing horrible laggy behaviour. It works perfectly in webkit browsers and IE7. While not exhaustive I've tried it in a number of FF versions and all are prone to the laggy behaviour, including 3.5 betas.</p> <p>Attached is a test case and a screenshot of a firebug profile showing the dominating functions(may or may not help).</p> <p>It looks like mootools is doing a lot of work, perhaps it can be optimised.</p></div> 23242 0 true 2009-07-14T09:39:27+01:00 62670 41986 91 mootools-12-drag-drop-flaw 2 24057 invalid drag 2009-09-14T07:32:34+01:00 23242 Aaron Newton cliffton Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/91 1.2.4.1 hi, I am building a drag & drop page base on the Drag.Cart demo. However I am using 1.2 core + plugin. Everything works ok except for the handling of "emptydrop" part. 1.11 version handles this beautifully with the "emptydrop" event. But now, eveytime when I click on a draggable item without dragging it and release the mouse click (mouse up), a clone will be injected into the document and stays there without being disposed. This problem no longer exists when the item is being dragged. Does anyone has any idea to go around this problem ? This is a nice piece of code from mootools. Thanks. window.addEvent('domready', function() { var drops = $$('.drop_area'); $$('.item').each(function(item) { item.removeEvents(); item.addEvent('mousedown', function(e) { e.stop(); var clone = this.clone() .setStyles(this.getCoordinates()) .setStyles({'opacity': 0.7, 'position': 'absolute'}) .inject(document.body); var drag = clone.makeDraggable({ droppables: drops, onComplete: function() { this.detach(); }, onEnter: function(el, over) { over.tween('background-color','#98B5C1'); }, onLeave: function(el, over) { over.tween('background-color','#fff'); }, onDrop: function(el, over) { if(over) { // do something ... over.tween('background-color','#fff'); } clone.dispose(); } }); drag.start(e); }); }); }); hi, I am building a drag & drop page base on the Drag.Cart demo. However I am using 1.2 core + plugin. Everything works ok except for the handling of "emptydrop" part. 1.11 version handles this beautifully with the "emptydrop" event. But now, eveytime when I click on a draggable item without dragging it and release the mouse click (mouse up), a clone will be injected into the document and stays there without being disposed. This problem no longer exists when the item is being dragged. Does anyone has any idea to go around this problem ? This is a nice piece of code from mootools. Thanks. window.addEvent('domready', function() { var drops = $$('.drop_area'); $$('.item').each(function(item) { item.removeEvents(); item.addEvent('mousedown', function(e) { e.stop(); var clone = this.clone() .setStyles(this.getCoordinates()) .setStyles({'opacity': 0.7, 'position': 'absolute'}) .inject(document.body); var drag = clone.makeDraggable({ droppables: drops, onComplete: function() { this.detach(); }, onEnter: function(el, over) { over.tween('background-color','#98B5C1'); }, onLeave: function(el, over) { over.tween('background-color','#fff'); }, onDrop: function(el, over) { if(over) { // do something ... over.tween('background-color','#fff'); } clone.dispose(); } }); drag.start(e); }); }); }); <div><p>hi,</p> <p>I am building a drag &amp; drop page base on the Drag.Cart demo. However I am using 1.2 core + plugin. Everything works ok except for the handling of "emptydrop" part. 1.11 version handles this beautifully with the "emptydrop" event. But now, eveytime when I click on a draggable item without dragging it and release the mouse click (mouse up), a clone will be injected into the document and stays there without being disposed. This problem no longer exists when the item is being dragged. Does anyone has any idea to go around this problem ? This is a nice piece of code from mootools. Thanks.</p> <p>window.addEvent('domready', function() {</p> <pre> <code>var drops = $$('.drop_area'); $$('.item').each(function(item) { item.removeEvents(); item.addEvent('mousedown', function(e) { e.stop(); var clone = this.clone() .setStyles(this.getCoordinates()) .setStyles({'opacity': 0.7, 'position': 'absolute'}) .inject(document.body); var drag = clone.makeDraggable({ droppables: drops, onComplete: function() { this.detach(); }, onEnter: function(el, over) { over.tween('background-color','#98B5C1'); }, onLeave: function(el, over) { over.tween('background-color','#fff'); }, onDrop: function(el, over) { if(over) { // do something ... over.tween('background-color','#fff'); } clone.dispose(); } }); drag.start(e); }); }); </code> </pre> <p>});</p></div> 28080 0 true 2009-06-11T03:44:19+01:00 59665 41986 72 mootools-more-1222-safari-4-elementsimplement 1 24057 resolved 2009-08-19T20:47:40+01:00 28477 Scott Kyle Aaron Dixon Sebastian Markbåge http://mootools.lighthouseapp.com/projects/24057/tickets/72 1.2.4.1 When I include MooTools-More 1.2.2.2 and use Elements.Implement in Safari 4 (Windows) I get a xxx [undefined] is not a function error. This error goes away if I take the reference to MooTools-More out. Elements.Implement({ myMethod:function() { return true; } }); func = function() { $$(el).myMethod(); } window.addEvent("domready", func); When I include MooTools-More 1.2.2.2 and use Elements.Implement in Safari 4 (Windows) I get a xxx [undefined] is not a function error. This error goes away if I take the reference to MooTools-More out. Elements.Implement({ myMethod:function() { return true; } }); func = function() { $$(el).myMethod(); } window.addEvent("domready", func); <div><p>When I include MooTools-More 1.2.2.2 and use Elements.Implement in Safari 4 (Windows) I get a xxx [undefined] is not a function error. This error goes away if I take the reference to MooTools-More out.</p> <p>Elements.Implement({</p> <pre> <code>myMethod:function() { return true; } </code> </pre> <p>});</p> <p>func = function() {</p> <pre> <code>$$(el).myMethod(); </code> </pre> <p>}</p> <p>window.addEvent("domready", func);</p></div> 23242 0 true 2009-07-13T23:59:52+01:00 53118 41986 90 tips-change-from-thisposition-to-thissetposition-refert 3 24057 resolved 2009-07-14T16:44:10+01:00 23242 Aaron Newton Thomas Allmer Aaron Newton http://mootools.lighthouseapp.com/projects/24057/tickets/90 1.2.4.1 the namechange from postion to setPosition in Element.Dimensions.js and has nothing to do with Tips this.position right? so you should revert the change from this.position to this.setPosition as Tips has it's own position function... and yeah it won't work with setPosition... right? it's just 2 replacements... do you need a pull request / patch for that? the namechange from postion to setPosition in Element.Dimensions.js and has nothing to do with Tips this.position right? so you should revert the change from this.position to this.setPosition as Tips has it's own position function... and yeah it won't work with setPosition... right? it's just 2 replacements... do you need a pull request / patch for that? <div><p>the namechange from postion to setPosition in Element.Dimensions.js and has nothing to do with Tips this.position right?</p> <p>so you should revert the change from this.position to this.setPosition as Tips has it's own position function... and yeah it won't work with setPosition... right?</p> <p>it's just 2 replacements... do you need a pull request / patch for that?</p></div>