2010/9/30 Trevor Parscal <tparscal(a)wikimedia.org>rg>:
* Where it is
suspected that, due to caching issues, the debug code
may not be the same as the minified code.
Shift+refresh?
Or change the URL
in some way that doesn't alter the meaning of the
URL. There's various ways to get around caching.
* To debug the
minifier itself, which is far short of a full
JavaScript parser and may well introduce functional differences.
If JSMin is
causing the bug, then it will be best detected by seeing
that debug=true/false have different behavior, not that debug=true
contains line breaks.
JSMin causing a bug sounds very unlikely to me, but I agree
that we
should be paranoid and account for the possibility anyway. Still, I
think we can agree that JSMin breaking something should be a very,
very rare occurrence (it's been around for a long time and has been
used on a large body of code), and that debugging the minifier would
be done locally anyway (to be sure caching is not to blame), so line
breaks in production won't help. All you'd need to debug JSMin locally
without going insane is to be able to preserve line breaks locally,
which can be accommodated with a setting (off by default) or even just
requiring commenting out of code (as long as it's clear how to do this
and not cumbersome, this should be fine).
but depending on the
user's preferences they may be totally different from one user to
another.
This is false in almost all cases. Because we make our requests as
cacheable as possible, the vast majority of RL responses will *not*
depend on user preferences, or in fact on anything not in the URL. For
these requests, you'll be able to pull up the same URL that the user
is pulling and see the exact same thing (provided you both clear your
caches). User preferences and other factors may be used to *build* the
URL, so whether you see the issue may depend on your preferences, but
once you find out which URL the user is getting their stuff from
you'll have a meaningful line number.
There should only be one request whose contents depend on user
preferences: the one getting the user's preferences plus the user
scripts. The former is really just one call to a setter with a
JSON-encoded preferences map, so it consists of one simple statement;
inspecting that is doable. The rest is the user's own user JS, which
can contain almost anything. This is the only thing you won't
reasonably be able to debug based on just a line number, but then
there's lots of other easy ways to nail down user JS as being the
culprit.
Line numbers in production mode (debug=false) are
useless no
matter how much white-space is preserved.
Per the above this is not entirely true,
but the one case in which
they are useful (culprit is in user JS+prefs request and all you have
is a line number) doesn't warrant preserving line breaks IMO.
We should probably calculate just how small that cost
is before we start
making asumptions based on it being "fairly small".
I agree that we
should get our numbers first, but some preliminary
playing around seems to indicate Tim's right about this one.
Roan Kattouw (Catrope)