> and therefore did not liked it, when frequently changes broke their setup.
Which is unfortunately an inherent problem with our legacy customization approach.
And it is clearly not something the vast majority of users want, if they left Firefox for another browser that appears to them less customizable but more stable. We have run numerous user studies about what users actually care for and they have all informed what Firefox is going to be in the future.
about:permissions was an incomplete experimental UI, but a fully functional replacement is high on our priority list. We are waiting on a new design from the UX team at the moment.
This is exactly right that X means "close" or "hide this thing" and this is what it does in this case as well: it removes the non-default setting and hides the list item.
There have been a number of user studies done by Mozilla and other browser vendors that clearly show end users only have a basic grasp of the security properties of the web. So yes, more details in main UI elements leads to confusion. It's just 2 clicks for those of us who know what a certificate is (Ctrl/Cmd-I is even faster).
You are pretty much describing the Firefox architecture. We are invoking Firefox UI code from scratchpad all the time when prototyping things. Some parts of the UI do not use standard Web APIs (e.g. XUL and XBL), as there are different opinions on how the web platform should evolve to fulfill those needs, but if you include all the experimental technologies to this web kernel, we are already there.
Mozilla has been paying the main Firebug developer for a long time to work on it, but I've never heard of an open source project that would like to be "acquired", whatever that means. If hiring all of the project's developers is what you mean, quite a few of them had high profile jobs already, so funding wasn't an issue here. As for the reasons why simply incorporating Firebug into Firefox wasn't a viable solution, see the original post.
As mentioned on the hacks post, ever since Firefox 23 the web console is actually working on the same context as the debugger, when execution is paused on a breakpoint or debugger statement. You can use all the familiar tools in there to examine the current state of the page.
Mozilla can't kill Firebug, even if they wanted, since it's a separate open source project and community. And the only people with two inspectors would be those that elected to have them both, by installing Firebug and using both tools.
In order to get to that modal message, you first have to go and enable remote debugging, which is not something normal people would do. And in general, even though we can (and already have) come up with even more mitigations for the potential threat, the sad truth is that security and usability are fundamentally a tradeoff, so you have to strike a balance at some point.
Allowing websites to interact with the Debugger API is something we would like to do, but, as you note, the security implications require much more thought to get it right.
That comment taken out of context can be quite alarming, indeed. Firebug, until recently, had two developers who were paid to work full time on it (jjb from IBM and Honza from Mozilla) and a number of people who contributed in their spare time. Now it's down to one full-time developer paid to work on it (Honza) and a number of people who still contribute in their own time.
Erm, narwhal actually uses rhino as its default engine. Perhaps you meant to say that you can now target the narwhal API, instead of waiting for rhino to expand its API offerings?
Besides being an incredibly powerful combination of a functional and an object-oriented language, I just adore the fast redeployment cycle during development. With appenginejs, I test every change in the backend code by simply refreshing my browser. Not jaw-droppping per se, but certainly a breath of fresh air for a long-time "enterprise" Java developer, like me.
Ah, the void of non-existence is certainly filled with emptiness. It's what happens to the living that matters, though. Put another way, is Schrödinger's cat alive or dead? Does it matter if you don't intend to open the box?
Actually the recently announced austerity plan has been the hardest ever for the people here, at least since democracy was restored in 1974. And the soon-to-be-announced revised austerity plan mandated by the IMF is rumored to be the hardest thing since WW II. It's not certain that the plan's goals will be met of course, but you can be sure that this time the politicians are not only caring about their re-election.
I don't remember having seen his name for a long time in any technical discussion or decision involving Java, besides Closures, where he co-authored the BGGA proposal. Although it appears that Gafter and Bracha put more work in that one. Even then he did not apparently have enough say on the matter to make his blessed proposal official. His main role seems to be an evangelist for the platform and perhaps researcher for some more involved areas, like real-time systems and numerical processing, AFAICT from his blog posts.
I wish Windows supported WebDAV in a sane way. They seemed keen to do so around Windows XP, but they apparently changed plans. They have two stacks, the more standards-compliant one (Web Folders) is deprecated and won't run in many new versions of Windows and the old one is way too buggy and suffering from bit-rot.
There is an explosion indeed, with two main directions IMHO:
- frameworks like yours on top of Node
- frameworks like helma-ng and nitro on top of Google App Engine (via Rhino)
These offer the best scalability guarantees and I'm still torn on what is the best approach for my personal projects.
It can be used for adding a vi mode to any web page editing scenario you might have a need for. If you want to edit local files from your browser, I've made a Firefox extension that does just that: