how to shoot yourself in the menu with a variable

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.. 😦

Advertisements

8 thoughts on “how to shoot yourself in the menu with a variable

  1. Man, you are doing a great job!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?..

  2. I guess David has a better overview of that. A quick search of open and closed issues show roughly 25% success, but the trend is upward since David started so many of the unresolved issues are hopefully older ones.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 🙂

  3. browser.js is indeed a great thing!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.

  4. I think a "don't patch" list of URLs would do the trick. Quick and simple…PS. Blame me for the problematic Likno version test 😮

  5. "don't patch" list of URLs[/url]Slightly ajar, hm? Wouldn't this be better:

    if (opera.procSig('Pixelate')=='5915d348' && opera.procSig('awmshowdiv')=='b658edee') //assume v.625
  6. Interesting ideas. The main problem (for any idea in this space) is the number of iterations/versions of menus and the fact that we don't have any complete reference of them. If there are 626+ builds of AllWebMenus out there – plus any changed by webmasters at random – and they can contain variables customised by the software that generates an AllWebMenu, checksums seem like a rather daunting approach, and regexp or string search only marginally better..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 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s