Randomly failing router regexp on native Android browser

I've encountered a very, very strange bug with enyo's router on Android Browser. My application has multiple 'pages' each with its own route. One of the paths in my application is: episode/:episode. The token regexp - /\:[a-zA-Z0-9]*/g - detects this particular path as dynamic on every browser except for the native Android browser.

Basically, when the path is added to the router and the test is evaluated by the router itself, it fails.
However, if I then test the token manually by typing it in the console, it works just fine and the test passes. Very strange...

The solution, in my case, was to remove the 'global' flag from the regexp: /\:[a-zA-Z0-9]*/ The router seems to work just fine that way, and Android browser once again recognizes episode/:episode as a dynamic path.

Is this something worthy of opening a ticket? Or is it too exotic to be worth it? I'm not sure if I can easily recreate a minimal test-case, considering the fact that things work fine for everyone else and even work fine in the console in the very browser that's causing the problem.

Comments

  • edited December 2014
    Here's my (untested) guess ... Specifying the global option is probably bad in this case. When using the global option, the RegExp object remembers the last index (in the appropriately named lastIndex field). So, each time you exec() it, it starts at that index. If it fails to find a match, lastIndex is reset to 0 so the next exec() works.

    Enyo isn't cloning the RegExp for each request so that's probably what you're running into. If you think there's a use case for global expressions, let me know and we can file a bug and decide how to handle.

    > var re = /\:[a-zA-Z0-9]*/g;
    < undefined
    > re.exec(':item:item')
    < [":item"]
    > re.lastIndex
    < 5
    > re.exec(':item:item')
    < [":item"]
    > re.lastIndex
    < 10
    > re.exec(':item:item')
    < null
    > re.lastIndex
    < 0
    > re.exec(':item:item')
    < [":item"]
    > re.lastIndex
    < 5
  • I did not know that, but you could be onto something there. Currently the global flag came from enyo's source. Like you suggested, I don't think I see any need for the expression to be global. I'll open a ticket and roll a patch.
  • Oops, just noticed it was already fixed. I checked the token on master, but missed the fact that lastIndex is already being reset.

    I also figured out the global flag is needed too, because it's used when constructing the new regexp to extract the the token's values from the full url.

    I created this ticket before noticing it was already fixed: https://enyojs.atlassian.net/browse/ENYO-4118
    Feel free to close it.
Sign In or Register to comment.