pvdung / ourlibrary Goto Github PK

These were clearly created in the wrong place (in a document ready 
listener).  Will move on next update.

JFTR, you should always inherit from E and Q on document ready.  Unlike the 
others, those two global constructors are hybrids (which allows for some 
functionality during loading.

http://www.cinsoft.net/mylib-doc0.html#hybrid

What steps will reproduce the problem?
1. run API.alert to display an alert
2. modify the content of the alert so the content takes up more space
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Some of the drag tests on the Build Test page have absolutely positioned 
elements with only a left style declared (no top).  This isn't an issue for 
competent implementations of getComputedStyle, but Konquerer 4 has issues 
where it returns 0, regardless of the actually top position.

This will be fixed by using the code form this primer, which does not rely 
on getComputedStyle at all.  Will also allow for retrieving the bottom/right 
positions reliably.

http://www.cinsoft.net/position.html

API.urlencode("foo bar baz") => `foo+bar%20baz`

What steps will reproduce the problem?
A.
1. Create HTML including a select element with *zero* selected options.
2. Call API.inputValue() with the select element as the parameter.
3. Returns an empty array.

B.
1. Create HTML including a select element with attribute "multiple" and *one* 
selected option.
2. Call API.inputValue() with the select element as the parameter.
3. Returns a single string.



What is the expected output? What do you see instead?

A. Expect a falsy value, but get an empty array, which will evaluate to true.


B. Expect an array of values (regardless of the number of selected values), but 
receive a single value.

What version of the product are you using? On what operating system?

Builder version on 2011-07-16



Please provide any additional information below.

// The current code looks like this:

inputValue = function(el, bDefault) {
    var a, o, t = el.type;

    if (t && !t.indexOf('select')) {
        a = [];
        for (var j = 0, jlen = el.options.length; j < jlen; j++) {
            o = el.options[j];
            if (o[(bDefault)?'defaultSelected':'selected']) {
                a[a.length] = getOptionValue(o);
            }
        }
        if (a.length == 1) { a = a[0]; }
        return a;
    }
    . . .
};

// I would propose that the line:

if (a.length == 1) { a = a[0]; }

// . . . be replaced by something like:

var alen;
if (!el.multiple) {
    alen = a.length;
    if (alen == 0) {
        a = null; // perhaps a different falsy value?
    } else if (alen == 1) {
        a = a[0];
    }
}

I'm not sure about this, but what I know is that when I change an image
with a fade effect, if my image has a z-index > 0, it covers the overlaid
image and the fade cannot be seen.

My guess is that overlayElement should check for a z-index and set the
temporary element's z-index to elzIndex++.

fixed with change:

        importNode = function(node, bImportChildren, docNode) {
          var i, name, nodeNew, nodeChild, value,len;

          docNode = docNode || global.document;
          switch (node.nodeType) {
          case 1:
            nodeNew = createElement(getElementNodeName(node), docNode);
            if (nodeNew) {
              if (node.attributes && node.attributes.length) {
                i = node.attributes.length;
                while (i--) {
                  if (node.attributes[i].specified) {
                    name = node.attributes[i].nodeName;
                    value = getAttribute(node, node.attributes[i].nodeName);
                    if (value !== null) { nodeNew = setAttribute(nodeNew, name, value); }
                  }
                }
              }
              if (bImportChildren && node.childNodes && node.childNodes.length) {
                len = node.childNodes.length;
                for(i=0;i<len;++i)
                {
                  nodeChild = importNode(node.childNodes[i], bImportChildren, docNode);
                  if (nodeChild) {
                    if (nodeChild.nodeType != 1) {
                      if (elementCanHaveChildren(nodeNew) && (reNotEmpty.test(nodeChild.data) || getElementNodeName(nodeNew) == 'pre')) {
                        nodeNew.appendChild(nodeChild);
                      }
                      else {
                        if (getElementNodeName(nodeNew) == 'script' && typeof setElementScript == 'function') {
                          setElementScript(nodeNew, nodeChild.nodeValue);
                        }
                      }
                    }
                    else {
                      if (elementCanHaveChildren(nodeNew)) {
                        nodeNew.appendChild(nodeChild);
                      }
                    }
                  }
                }
              }
              return nodeNew;
            }
            break;
          case 3:
            return docNode.createTextNode(node.nodeValue);
          }
        };

getElementSizeStyle leaves height and width inline styles on elements, which 
overrides the default for both styles in elements (auto).

Here's the suggested patched getElementSizeStyles
getElementSizeStyle = function(el) {
  var dim = [];
  var tmpDim = [];

  dim[0] = getStylePixels(el, 'height');
  dim[1] = getStylePixels(el, 'width');
  if ((dim[0] === null || dim[1] === null || computedSizeBad)) {
    if (typeof el.offsetHeight == 'number') {
      dim[0] = el.offsetHeight;
      dim[1] = el.offsetWidth;
      tmpDim[0] = el.style.height;
      tmpDim[1] = el.style.width;
      el.style.height = dim[0] + 'px';
      el.style.width = dim[1] + 'px';
      adjustElementSize(el, dim);
      el.style.height = tmpDim[0];
      el.style.width = tmpDim[1];
    }
    else {
      return null;
    }
  }
  return dim;
}; 

What steps will reproduce the problem?

// Contrived example.
API.every(['one', 'two'], function(word) {
  window.alert(word);
  return false;
});


What is the expected output? What do you see instead?

Only 'one' should be displayed.
Only 'two' is displayed.


What version of the product are you using? On what operating system?

Full version from Builder @ Sat, 24 Apr 2010 02:05:12 UTC
Win2k/IE6


Please provide any additional information below.

Per ECMA-262 5th Edition, the array enumeration functions (every, some, 
filter, etc) should operate on each element of the array "in ascending 
order."  Since the native function is used when available, the replacement 
should operate the same way.

I believe only 'every' and 'some' are incorrect as the other enumeration 
functions do not need to short circuit.

What steps will reproduce the problem?
1. grab a build of mylib.js and include it in a page
2. add `<script>API = { deferAudio = true };</script>`
3. try to use getEBI or getEBTN or ...

What is the expected output? What do you see instead?
I expect the method to return the appropriate element. Instead I get 
"TypeError: Result of 
expression 'API.getEBTN' [undefined] is not a function." (could be getEBI, 
getAttribute etc.). 
Comment out the line that sets deferAudio to true and everything works as 
expected.

What version of the product are you using? On what operating system?
Sun, 28 Mar 2010 22:49:28 UTC

Please provide any additional information below.
attached is a simplified test case.

As the subject of hasClass came up today, I confirmed my suspicion that the 
hasClass module was sound for multiple class names and that the older logic 
in the query module, which was "duplicated" inline for performance was not.  
Actually, I think that part of the query module predates the hasClass 
function.  The issue is class names separated by white space other than 
spaces (like carriage returns).  Needless to say something that is easily 
avoided.  I think I prefer an instant failure for such ridiculous markup (a 
la getEBI letting the ID/name thing blow up in IE)  I'm going to think about 
it, but the two certainly need to agree.   :)

Subject of memoization came up too.  It's been on my list for a while to 
memoize hasClass and a few other functions that create regular expressions.

If effects are available, the new changeImage function creates an overlay
and attaches it to the body element. This could cause issues if the image's
parent element has overflow set to hidden and the image overflows the
container dimensions. As the overlay gets attached to the body, while the
effect is transitioning, the image overflows its container.

My proposed new version of that function follows below.

if (typeof changeImage == 'function') {

        oldChangeImage = changeImage;

        changeImage = (function() {

          if (canAdjustStyle.visibility && canAdjustStyle.display && body
&& isHostMethod(body, 'cloneNode') && isHostMethod(body, 'appendChild') &&
isHostMethod(body, 'removeChild')) {

            return function(el, src, options, fnDone) {

              var elTemp;

              var docNode = getElementDocument(el);

              var parent = getElementParentElement(el) ||
getBodyElement(docNode);



              var done = function() {

                oldChangeImage(el, src);

                showElement(elTemp, false);

                body.removeChild(elTemp);

                elTemp = null;

              };



              if (options && options.effects) {

                elTemp = el.cloneNode(false);

                elTemp.id = elementUniqueId(el) + '_temporaryoverlay';

                oldChangeImage(elTemp, src);

                elTemp.style.visibility = 'hidden';

                elTemp.style.display = 'none';

                elTemp.style.position = 'absolute';

                elTemp.style.left = elTemp.style.top = '0';

                parent.appendChild(elTemp);

                elTemp.style.display = 'block';

                overlayElement(elTemp, el);

                showElement(elTemp, true, options, function() { done(); if
(fnDone) { fnDone(el); } });

              }

              else {

                oldChangeImage(el, src);

                if (fnDone) { fnDone(el); }

              }

            };

          }

          return oldChangeImage;

        })();

Additional feature testing may be needed, as I'm not sure if the fact that
body has appendChild assures that the element's parent node also has that
method available.

As has been discussed, I stopped just short of a full CSS3 query engine.  
Still need to add support for leading combinators, the not: psuedo selector 
and multiple pseudo selectors.  Once those are wrapped up, I will add 
functions and methods to test nodes and filter queries.  These features will 
be in the first release.

What steps will reproduce the problem?
1. Include the HTML module

What is the expected output? What do you see instead?

Throws a RangeError exception on the line that uses insertAdjacentHtml to 
insert an HTML snippet with inline code in a SCRIPT element.

Will likely just wrap it in a try-catch and fall back to setting innerHTML, 
then the rest of the test can proceed.  JFTR, inserting HTML with inline 
code is a bad idea, period.  Trying to allow too much with this.

What steps will reproduce the problem?
1. Call "API.alert('Text')" - with no options argument.
2. Check for Javascript errors.

What is the expected output? What do you see instead?
It should show an alert dialog. Instead, it throws a exception.

What version of the product are you using? On what operating system?
Full My Library build (2-Sep-2010 at 4pm EST).
The widgets add-on built 2010-05-05.
The alerts add-on built 2010-05-07.
Browser: FF 3.6 on Windows XP.

Please provide any additional information below.
Can be avoided by replacing line 1225:
  var isFixedChecked = isChecked(elFixButton);
... with this:
  var isFixedChecked = elFixButton && isChecked(elFixButton);

The maximizeElement function, which is used by the Alert add-on needs to 
resize elements on resizing the window.

What steps will reproduce the problem?
1. add mylib.js to a page
2. load the page and watch the network

What is the expected output? What do you see instead?
I expect a single request for mylib.js. Instead I see a request for mylib.js 
and docs/c.html.

What version of the product are you using? On what operating system?
Sun, 28 Mar 2010 22:49:28 UTC

This is an oldie (and not a goodie).  I think it was the first function I 
contributed to the CWR project.  Apparently I didn't give it a lot of 
thought at the time (a recurring theme as I renovate).

We should really have a getElementOwnerDocument and a 
getElementParentDocument with the original combined version deprecated.  The 
(internal) attachListenerFactory function should be untangled in similar 
fashion (it uses getElementDocument in a really bad way).

At line #4008, the - callback - function returns this:
   return !ondrag || !callInContext(ondrag, callbackContext, c, co);

Which would cause this function to return true if the - ondrag - callback
returns false. I'm guessing that the desired behavior is the opposite.

So, the correct return might be
   return !ondrag || callInContext(ondrag, callbackContext, c, co);

Patched partial build attached.

As discovered testing frame-enabled widgets (e.g. Toast), this function had 
a typo that allowed for exceptions in some cases involving IFRAME elements.

As with other frame-related issues, this will be fixed in the next update.

The code that checks for API.getElementPosition needs to be wrapped in a 
document ready listener as the feature detection for that function is deferred.

Patched in builder.

They aren't supposed to have - b - arguments of course.  Those are from the 
corresponding - show - method signatures. Looks like a copy and paste 
mistake from way back.

Fix will be in the next update.  Sorry for any inconvenience.

As an aside, the use of toggle* is advised against.  Same as I would advise 
against a toggleClass function (though will put one in if asked).  Your app 
should keep track of whether it wants to show or hide the element.  Any 
reliance on computing styles to determine whether to show or hide an element 
complicates what should be (and often needs to be) a trivial matter.  If you 
want to support agents that do not compute styles (or do it poorly), you 
have to remember to set the inline display style.

What steps will reproduce the problem?
1. in side an event responder function
2. var theTarget = API.getEventTarget(e);
1. E(theTarget).setStyles({'background-color':'none','color':'none'});


What is the expected output? What do you see instead?
to set the element style attribute to 'background-color:none;color:none;'
as API.setAttribute(theTarget, 'style', 'background-color:none;color:none;'); 
will do.



What version of the product are you using? On what operating system?
Generated by My Library Builder v1.0  on Thu, 25 Mar 2010 17:54:42 UTC
Mac OS X 10.6.2


Please provide any additional information below.

What steps will reproduce the problem?
1. go to builder page select everything except stuff in "Combinations" and 
"Options" areas
2. click build
3. include the downloaded mylib.js in a page

What is the expected output? What do you see instead?
I expect no errors to be generated. Instead I see an error.

Safari: "ReferenceError: Can't find variable: restoreElement"
Firefox: "restoreElement is not defined"

What version of the product are you using? On what operating system?
Sun, 28 Mar 2010 22:09:11 UTC

Please provide any additional information below.
attached is a minimal test case.

I don't see any need to prune isDescendant in IE5.5.  This is why the auto-
hide button is absent from the sidebars on the test page.  I imagine the 
rollover test is inert as well, but haven't checked.

The feature detection is simply being too picky (because the HTML has a null 
parentNode).  Will change the test to check for the presence of the property 
as the HTML parent would be a document anyway.

What steps will reproduce the problem?
1. Attach an event to change images using - I.prototype.change - with a
fade effect when mouse goes over some elements
2. Mouse over elements :P

What is the expected output? What do you see instead?
I expect seeing a smooth fade effect when the image changes, instead,
*sometimes* (yes, that's weird), the new image slides from the left for
like 5px and the fade animation gets all chopped.

What version of the product are you using? On what operating system?
MyLib 1.0 on Slackware Linux. I couldn't reproduce the error on Google
Chrome, only Firefox. A buddy of mine also tried Firefox on Windows and saw
the same behavior.

Please provide any additional information below.
No exception gets thrown. There's a live version of the problematic page:
http://www.souagil.com.br/gabriel/myimagegallery/

Silly oversight that replaced the frame-enabled function with a simplified 
non-frame-enabled function.  Fixed locally.  Will be in the next build.  
This function no longer uses the lazy pattern at all, leaving 
getMousePosition as the only one that does.  Glad to be rid of that 
complication for this one.

Get the feeling I didn't test much with frames when this was first slapped 
together?  :)  Testing the new frames-based examples with widgets has 
illuminated a few problems.

Unlike the other "assisted" events, there is no corresponding off method 
on the wrapper objects.  Added calling detachRolloverListeners.  Will be 
in next update.

Adding to the documentation too.  Apparently that API function was a 
secret as well.  Finishing up the documentation has revealed a few 
surprises.  :)

There were a few typos in the attachDocumentReadyListener function 
related to frames.  Will not work for attaching ready events to frames.

Note that this is _not_ an issue for applications running in frames, 
but for applications attempting to attach ready listeners to documents 
in other frames. 

What steps will reproduce the problem?

1. With the following event response is setup in the script

E(doc.body()).on('mouseup',function(eventObject) 
                { 
                    var mB = API.getMouseButtons(eventObject);

                    if(mB.left)
                    {   
                        var myText = doc.getSelectionText();
                        if(myText)
                        {
                            window.alert(myText);
                        }
                    }
                });
2.  While using a webkit browser (Safari or Chrome) on a Mac
if the eventObject target is a <input type="submit" />


What is the expected output? What do you see instead?
since no text is selected, none.

What version of the product are you using? On what operating system?
built with the builder on Tue, 30 Mar 2010 17:18:00 UTC
Mac OS X 10.6.2

Please provide any additional information below.

What steps will reproduce the problem?
1. open the build test page with the drop target demo on IE8
2. try to drag the image on the drop target
3.

What is the expected output? What do you see instead?
you should see the image when hovering the drop target zone
instead the image disappear when you are hovering over the fieldset
the OVER message appears only if you drop it first

What version of the product are you using? On what operating system?
XP IE8

Please provide any additional information below.
The OUT message is returned correctly

In documenting the OO interface, some oversights have come to my attention.  
A few methods (e.g. attachDrag, detachDrag, initiateDrag) are missing the 
requisite "return this" lines at the end.

Will be fixed in the next (imminent) update, along with the other two open 
issues.  Sorry for any inconvenience.

Testing the new Toast widget, noticed there is one line in the function 
where "global" is used instead of "win" (the variable that holds the window 
reference, which may not be the primary window).

Fixed locally.  Will be in next update.  Won't patch the builder source in 
the interim (as has been done for other fixes) as the next full update is 
imminent (and anything related to frames is considered a minor issue at the 
moment).

The document argument should be optional

Any ongoing effects should be stopped (automatically completing their run) 
on the next call to position/sizeElement (with the same element).

The logic is wrong on these two functions in that they only cancel on the 
start of a new effect (and not without a specified effect).

Changed locally and also added return of EffectTimer object so that callers 
can stop the effect (completing it or not per the one argument to the stop 
method) without calling position/sizeElement again.

When called, API.getEBCS("[class~=foo]") returns partial class name
matches, ie: foo-bar, foo-whatever.

This goes against the CSS Selectors specs and therefore, QSA.

Both E.prototype.sizeStyle and API.getElementSizeStyle are missing from the
documentation. The only place the latter shows up in cinsoft.net pages is
at the "S is for Size" primer.

document.documentElement.scrollHeight always reports the viewport height 
instead of the root element's height. I've added a check on my local file that 
sets the display style of the body element to "none" and then check if  
scrollElement.scrollHeight is greater than zero. According to my local tests 
this fixes the problem and doesn't impact on other browsers.

Here's the modified version of the said function:

      getViewportScrollSize = (function() {
        var cm, addMargin, bd, sh, scrollHeightUnreliable, body;

        if (typeof getElementMarginsOrigin == 'function') {
          cm = getElementMarginsOrigin(containerElement);
          // IE quirk with scrollWidth/Height + HTML element margin
          addMargin = (scrollElement.offsetWidth == cm[0] + scrollElement.scrollWidth);
        }

        if (typeof scrollElement.scrollWidth != 'undefined') {
          // Firefox 3.6 reports the viewport height on documentElement.scrollHeight
          body = getBodyElement();
          bd = body.style.display;
          body.style.display = 'none';
          sh = scrollElement.scrollHeight;
          body.style.display = bd;
          scrollHeightUnreliable = (sh !== 0);
          if(!scrollHeightUnreliable)
          {
            return function(docNode) {
              var se = getTopRenderedElement(docNode);
              return [se.scrollHeight + ((addMargin)?cm[0]:0), se.scrollWidth + ((addMargin)?cm[1]:0)];
            };
          }
        }
        if (typeof global.document.width != 'undefined') {
          return function(docNode) {
            docNode = docNode || global.document;
            return [docNode.height, docNode.width];
          };
        }
        if (typeof scrollElement.offsetWidth != 'undefined') {
          return function(docNode) {
            var ce = getTopRenderedElement(docNode);
            return [ce.offsetHeight, ce.offsetWidth];
          };
        }
      })();

I have also attached my modified build.

What steps will reproduce the problem?
1. Go to the online My Library builder: 
2. Select only the Event, Image, and Image > Preload modules.
2. Click the "Test HTML" button.
3. Results in the following Javascript error: "'createElement' is not
defined" (on line 303)

What is the expected output? What do you see instead?
 * There should be no Javascript errors. Instead I got a Javascript error
with the message "'createElement' is not defined".
 * The Event test button ("Click Me") on the "Test HTML" page should be
enabled whenever building the "Event" module (on most browsers). Instead,
it is disabled.

What version of the product are you using? On what operating system?
 * My Library: only the Event, Image, and Image > Preload modules (using
the online builder around 5:30pm on April 14, 2010)
 * Browsers: Firefox 3.5.7 and IE8. (This issue should be browser-independent)
 * OS: Windows XP Pro SP3

Please provide any additional information below.
 1) I don't see the variable "createElement" declared anywhere in the
custom build, so the error is a valid one.
 2) When I try to build only the Event module _or_ the Event and Image
modules, I don't get any errors and attachListener is available (which is
unexpected). My best guess is a bug in the builder's dependency
calculation, something to do with Image > Preload.

Thanks,
Ethan B

Attaching "mylib-busted.js"