- June 23, 2011
- Categories: Clientside, Mootools
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/24/d152177141/htdocs/techblog.tonycollings.com/wp-content/plugins/code-highlighter/geshi.php on line 2147
This post really is for personal reference and if anyone, surfing the internet is looking for an answer to this particular problem, finds this remotely helpful then I'm glad I could have helped out!
THE PROBLEM: setInterval(); and setTimeout(); calls weren't being honored in Safari. Safari only. Everything else was perfect. I was building a basic slide show on one of our websites with some cross-fading action using the fabulous MooTools framework. However my first problem was that the website was running a legacy edition (1.11) of the MooTools framework so I had to dust of the 1.11 documentation. Code written; all worked beautifully in everything except Safari. I declared an array of images to use in my slide show, wrote a function to preload, inject and fade the image. This was then repeated on a timer using setInterval('myFunction()',6000);
Worked brilliantly in all but Safari.
Not being a Mac user (sorry Mac folks) I was initially frustrated at Safari's lag of debugging tools until I came across an article describing how in terminal you can enable a debugging menu. % defaults write com.apple.Safari IncludeDebugMenu 1
This is where all the detective work began. After enabling debugging I was presented with this error: NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7: An attempt was made to modify an object where modifications are not allowed
Some quick Googlin' later revealed that this is typically seen if you are trying to use the .innerHTML property when you've set your !DOCTYPE to XHTML. Hummh!? Never knew that. Turns out using .innerHTML in an XHTML !DOCTYPE is actually invalid markup. This blog article originally written in 2005 expounds on the semantics, however; it seems some browsers have actually built in tolerance to allow .innerHTML to be used in XHTML !DOCTYPE's, most, of course, except -webkit based browsers. Hello Safari!
So what does .innerHTML have to do with the slide show not working. Well... It turns out that all of the $(element).inject[where](); methods in MooTools 1.11 all rely on the following method. $(element).setHTML();
A quick look at that method in the source edition of the framework reveals:
... and there is the culprit
this.innerHTMLSOLUTION: Modify the .setHTML method to use another method included in MooTools 1.11
... VOILA! Now when I .injectInside() after preloading the image I'm using markup that Safari considers valid. Problem solved!
Further Reading
- January 18, 2010
- Categories: Clientside, Mootools
OK, interesting little issue we came across today. Figured I'd share this in-case anyone else is going through the same unsettling couple of hours we just went through.
Our company has a Sonic firewall. The people over at Sonic release security updates (logical); in particular this one :
SonicWALL - MS IE mergeAttributes Function Invocation (http://software.sonicwall.com/applications/ips/index.asp?ev=sig&sigid=3099)This is to patch a known vunerability in; surprise, surprise Internet Explorer :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0247
(MSDN:: http://www.microsoft.com/technet/security/Bulletin/MS10-002.mspx - 21JAN2010).
Unbeknownst to me this occured at 16:00 yesterday (26th Jan 2010) automatically. After receiving a phone call this morning; pretty much to the affect of : "the website is down", spiraled a series of events that ended up with me looking for Javascript object/variable conflicts in 3rd party supplied vendor code.Using the savior that is Firebug (thank you Joe Hewitt and a dedicated community) I was quickly able to isolate the problem to a Javascript runtime error, in this particular case; the Mootools Fx() class. Because of this 'error' Mootools failed to run/compile and thus began a progressive series of 'domino effect' events. Mootools didn't execute window.addEvent('domready',function(){}), our AJAX content didn't execute and the page simply failed to load ("the website is down") ... I began having nightmares. Was Mootools now flawed because of some random browser update?
After quickly testing and noting that every single website I'd created using the Mootools library was also failing on the corporate LAN I began to feel a little light-headed. A hasty call to my wife, God Bless my external tester, quickly calmed my nerves after confirming everything worked perfectly outside of the LAN. OK, so it's internal only.
More frustratingly all the code worked flawlessly in our production environment. At this point I'm thinking firewall. "Any recent changes?" Turns out there was one... yesterday at 16:00. OK.
I'm not sure entirely what my firewall partner-in-crime did but it worked, altering the level of action taken on detection of this alert seemed to re-enable the site. From what I can understand of this threat is that if the firewall detects attempts to exploit this Javascript vulnerability it prevents the code from executing, in this case 'causing Mootools to fail and the website to simply 'not show up'.
I suspect it's because of our firewall configuration where we actually have to go outside of the firewall to come back in again. Any AJAX requests (or in this instance Mootools' new Asset.image() class/method). Content/Javascript is theoritically going outside of the firewall only to come back in again, thus 'causing the Firewall to detect this as a threat. A point possibly confirmed by the fact that this issue was only noticeable on websites where AJAX methods had been adopted to render data.
Anywhere; we're back in business, but I figured I'd share in case anyone else is currently looking for answers to this particular problem.
I've also posted this to the Mootools google.group for further incite from others. Follow the thread here
- September 19, 2009
- Categories: Clientside, Mootools, PHP
Very interesting debate, although anyone not technically inclined would consider my rationale for such a statement. These days there is a vast array of Javascript Frameworks on the internet each offering their own implementation of 'next generation' Javascript.
... are just a few, but seriously. Which one do you choose ? I came across this article tonight debating which is better between two of the top frameworks. "Mootools or jQuery : Choosing between two great frameworks".
Essentially if you're familiar with the selector concept and have an intermediate understanding of Javascript it's fairly easy to port between the two, but I thought it was an article worthy of sharing.