It seems we're all in agreement that startup time is an arbitrary metric largely irrelevant to our users. As such, the metric is the root cause of our troubles, and we can address it directly: move everything into setTimeout(setupFirebug, 0) -- the AMO optimization page even explicitly (and surprisingly) encourages this. afaict, doing so would drop our startup penalty to its minimum by their counting (whatever the cost to load our files from disk and instantiate overlays if done in the manifest). While this is still a non-trivial code change (having to protect anything that makes synchronous setup assumptions with a flag is annoying) it's certainly easier than any of the other options (refactoring the add-on to be tab-relative, identifying bottlenecks and optimizing them, or waging a marketing war for the hearts and minds of the average Firefox user).
The obvious disadvantage is that it's a stopgap effort. If we decide we actually care about startup time -- though all comments point toward NO -- then effort would be wasted. Otherwise, the biggest issue I can see is that AMO fails to be responsive in updating their list. Perhaps come May we'll find the whole thing had no impact on installs. In any case, this is ultimately not an engineering issue; it is a marketing issue. Our audience understands us, but Firefox users writ-large likely do not; the blokes at AMO have, perhaps unintentionally or with heavy hearts, acted to scapegoat Firebug in seeking advantage in the eternal browser wars. Leaving AMO clearly hurts publicity more than it helps. If we're going be judged on the cleanliness of our Potemkin Village, I vote we paint some cardboard houses. -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
