how to shoot yourself in the menu with a variable
Thursday, 6. April 2006, 18:47:22
Opera uses the Browser JavaScript feature to automatically fix older scripts that otherwise would not run correctly.
One of the interesting challenges of doing that is to work out how, exactly, browser.js can tell when Opera is about to run an "outdated" script that needs fixing? Because if we apply the fix to a modern script, we might break things instead of fixing them..
Until today I thought the AllWebMenus fix was one of the safest in the book. It takes advantage of the fact that every AWM script contains a "build number" variable showing what version the script is. This variable is not even part of the comments where webmasters might remove it, it is right there embedded in the script. It is also relatively unlikely (though not impossible) that other scripts would define a variable called awmBN with a value that would trigger the patch, and even more unlikely that the patch would break a script doing so.
OK, think again. Browser.js breaks the menu on Aquaria.info because the inline script says
var MenuLinkedBy='AllWebMenus [2]', awmBN='438';
while the script file the page links to actually reveals a much more recent build number:
//****** AllWebMenus Libraries Version # 626 ******
So the webmaster has changed the .js files to upgrade, but not bothered changing the script in the HTML file. Not such a safe patch after all..
Once I stop saying "d'oh" I'll have to figure out what to do about it.. :-(
One of the interesting challenges of doing that is to work out how, exactly, browser.js can tell when Opera is about to run an "outdated" script that needs fixing? Because if we apply the fix to a modern script, we might break things instead of fixing them..
Until today I thought the AllWebMenus fix was one of the safest in the book. It takes advantage of the fact that every AWM script contains a "build number" variable showing what version the script is. This variable is not even part of the comments where webmasters might remove it, it is right there embedded in the script. It is also relatively unlikely (though not impossible) that other scripts would define a variable called awmBN with a value that would trigger the patch, and even more unlikely that the patch would break a script doing so.
OK, think again. Browser.js breaks the menu on Aquaria.info because the inline script says
var MenuLinkedBy='AllWebMenus [2]', awmBN='438';
while the script file the page links to actually reveals a much more recent build number:
//****** AllWebMenus Libraries Version # 626 ******
So the webmaster has changed the .js files to upgrade, but not bothered changing the script in the HTML file. Not such a safe patch after all..
Once I stop saying "d'oh" I'll have to figure out what to do about it.. :-(
You must be logged in to write a comment. if you're not a registered member, please 
But can you provide some statistics: how many sites actually already improved (fixed) something and how many didn't after Opera sended them e-mails, made phone calls?..
By FataL, # 6. April 2006, 21:20:54
Recently David has been busy contacting sites, I have held back a bit giving the webmasters time to respond. Now we'll move on and patch those who igored us
By hallvors, # 6. April 2006, 23:18:31
In general and in this case in particular, no-one is actively trying to bypass Opera's hotfixes, most problems appear when "webmasters" do unpredictable things. And fixing via bJS has always been programming compromise.
The short-term solution is to increase the paranoia levels, thus slowing things down as the processed scripts in JS/HTML are checked against enough clues for a definite match.
One might imagine a long-term solution that involves some logic to determine what kind of scripts the page is invoking, something as simple as a CRC32 signatures for methods (maybe ignoring empty white-spaces), or as complicated as fuzzy logic to give confidence intervals.
All code online is a library that the webmaster may have tweaked since the bJS was placed in service. Who doesn't love the worst case scenario ?!
PS: CRC32 signatures of methods would of course be very useful for uJS, too.
By dantesoft, # 7. April 2006, 00:42:26
PS. Blame me for the problematic Likno version test
By Andrew Gregory, # 7. April 2006, 02:59:25
if (opera.procSig('Pixelate')=='5915d348' && opera.procSig('awmshowdiv')=='b658edee') //assume v.625By dantesoft, # 7. April 2006, 07:04:07
To err on the side of caution I want to move towards searching for and matching the exact "point of failure", for example a browser sniffer that doesn't detect Opera, or detects an "old" version. This is something Andrew's original menu fix script probably does better than browser.js due to our performance concerns. For performance, it should remain a two-step process: first detect a "suspicious" file name and then do a more expensive string search. Anyway, to get this done requires quite some time for analysing scripts that already are successfully patched, so it won't be high-pri and will happen gradually..
Now go play with the patched Blogger rich text editor in Opera 9
By hallvors, # 12. April 2006, 12:22:42
This is so original I'm sure 3com could get a patent on it..
http://www.3com.com/products/en_US/prodlist.jsp?tab=cat&pathtype=purchase&cat=19&selcat=Network+Interface+Cards+%26+LOMs
patching fun..
By hallvors, # 9. May 2006, 00:08:05
By qicai02, # 22. June 2006, 05:55:40