Analyzing Analyzer2

At the heart of Deimos, the graphical layout engine of Ares, is a bit of "extra" code called "Analyzer2"

We invoke Analyzer2 to parse a component to see if it is something we understand and something we can graphically manipulate via our Interface Builder (Deimos).

In modern Safari, everything is fine.

In the latest versions of Chrome and Firefox, Analyzer2 performs differently and renders Deimos broken.

I'm starting to delve into why but I'm wondering if anyone has insight?



  • Lurking in Walker.js is the problem (part of Analyzer2). This line is the offender:
    enyo.loader = this.loader;
    The reason this is bad is because we are hijacking the underpinnings of Enyo. Apparently this was "luckily ok" on some javascript interpreters but it is NOT ok for the javascript engines in Chrome and Firefox these days.

    The fix for this is not immediately apparent - it will take some head scratching. We are trying to easily use something in a way it is not supposed to be generally used rather than writing another branch of code...

    Deimos - it will take some keen insight to return you to your former glory.
  • I'm still very fuzzy but am wondering about RegExp in javascript. If it is somehow different in Safari vs Firefox / Chrome?

    Inside the Analyzer2/examples directory there is a "test.html" that flexes the lexer and parser then dumps information to the screen. It works great in Safari. In Firefox and Chrome it's in an infinite loop!
  • Fascinating! Look at this:


    Locate "analyzer.Lexer" - find where it is defined.

    Look at the method "buildPattern" inside of "analyzer.Lexer"

    It's building up a regular expression in here. Ok, great, but what is fascinating is that we get different output based on the web browser we are using.

    Safari generates this:
    Why is the same javascript building up differently?

    Is "\\/" even a valid Regular Expression bit?
  • edited June 2016
    Check out the pull i did a few years ago to fix reader.js in the

    i got a pull in LG exter libary

    when it reads in a line the analyzer can not handle any thing after a commint

    " /** @lends onyx.Button.prototype */ { " see the { after the comment

    LG did this in one of doc fix ( my oppion bad code to put code after a commit like that.

  • In Lexer.js in the "analyze" method it calls:
    var regex = new RegExp(this.pattern, "gi");
    That second parameter is no longer supported by Firefox and Chrome! That "gi" bit is ignored in Firefox and Chrome.
  • I figured out the bug! Wow!

    I will have a release available to install via NPM soon but there's the details of the issue:

    There was a problem with Deimos (Interface Builder in Ares) where in the latest versions of Firefox and Chrome they would fail to parse and fail to work. The user would be face with a cryptic error message when they hovered over the icon to open your Enyo component in the GUI. Safari did not have a problem.

    As it turns out, inside of Analyzer2 (where this Lexer.js resides) there is an examples folder with a "test.html" which allows you to see if a minimal Enyo Kind can be parsed. Safari had no problem with this but Firefox and Chrome got stuck in an infinite loop.

    Because Ares launches the Analyzer asynchronously, I believe the infinite loop scenario must bomb out pretty fast some how, hit some sort of time limit, I'm not sure. What I am sure of is that it improperly parsed the Enyo component you wanted to use and everything went south (in FF and Chrome, Safari was fine).

    Turns out the fix is right here, in the "analyze" function. For Firefox and Chrome the "search" on the regex would cause the "lastIndex" to start over again at zero. By merely adding some housekeeping to catch this "restart" condition everything now works in all three browsers.
Sign In or Register to comment.