mangalam-research/wed

requirejs optimization of wed fails mysteriously

lddubeau opened this issue · 2 comments

lddubeau commented

(This gist contains files mentioned in this report.)

Relevant version numbers

Chrome: 30.0.1599.101

$ node_modules/requirejs/bin/r.js -v
r.js: 2.1.9, RequireJS: 2.1.9, UglifyJS2: 2.4.0, UglifyJS: 1.3.4

Steps to reproduce

  1. Use the requirejs.build.js file in the gist.

  2. Make sure your selenium configuration is set to use Chrome as the browser.

  3. Issue:

    $ make selenium-test

Expected Results

No errors

Actual Results

Eventually, there will be an uncaught exception generated:

Uncaught TypeError: Object #<Y> has no method '_instantiateWalkers' validate.js:780

Observations

Note that the gist contains the validate.js file that was optimized using the requirejs.build.js file. The line numbers below refer to this file.

By setting Chrome to break on uncaught exceptions, I was able to stop the execution and examine the run time. What I found is really strange:

  1. The top of the stack trace shows:

    ee.fireEvent (validate.js:780)
    $.fireEvent (validate.js:661)
    ee.fireEvent (validate.js:783)
    se.fireEvent (validate.js:1009)

    $ is ChoiceWalker and ee is GroupWalker. At the location indicated in the stack trace in the 2nd position (from the top) ChoiceWalker.fireEvent is calling fireEvent on this.walker_a.

    When selecting the 2nd position in the stack above as the current one this.walker_a is an object of class Y. Y is OneOrMoreWalker. When using Chrome's console to examine this.walker_a.fireEvent, the function returned is the correct one.

    It seems that although this.walker_a and Y have the expected fields and definitions for fireEvent Chrome decides to call ee's fireEvent.

  2. The problem cannot be reproduced if, any of the following is true:

    • The code is not optimized at all.
    • The test suite is run in Firefox.
    • Compression is completely disabled: compress: false.
    • useStrict is set to false.
lddubeau commented

For the record,

  1. When the error described in the original bug report happens, wed is not in the process of being destroyed, nor already destroyed.
  2. Cache busing (using urlArgs: "bust=" + (new Date()).getTime()) does nothing.
  3. The bug cannot be reproduced using Chromium 29.0.1547.65.
lddubeau commented

The current solution is to leave useStrict to false, which is the recommended setting anyway.