On 9/30/10 10:11 AM, Roan Kattouw wrote: > 2010/9/30 Trevor Parscal<[email protected]>: >>> * 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. > Yes, thank you for correcting me here. In fact, we encode the user's name into the URL (but still limit access to the information to those with a matching session) so the URLs are all always unique to the response. >> 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) > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
