Значительные изменения в Firefox

не нужно передергивать.

Что должен делать браузер? Правильно, открывать страницы. Еще он должен содержать в себе нужные кнопки навигации, хистори, фейворитсы. Все. Возможно, этой функциональности большинству народу будет более чем достаточно. Все остальное является необязательным, так как большинству людей это просто не нужно.

Все, что требуется от разработчиков -- реализовать солидный api для плагинов. ВСЕ.

Разорались тут, source viewer им нужен. В опере его просто напросто нету. Для показа кода, opera просто напросто вызывает внешний текстовый редактор. Сомневаюсь, что "mozilla code browser" намного удобнее любимого текстового редактора.

Далее, download manager. Нахрен они его вообще прицепили, когда есть wget и тележка всяких графичесиких поделок? Почему бы было просто не приципить вызов внешней качалки?

Про менеджер профилей я вообще молчу. Данная херня вообще должна была умереть не родившись.

Что такое офлайновый режим я даже не представляю, поэтому ничего говорить не буду.

Кое-что нашёл в блоге Asa Dotzler'а, думаю многим будет интересно почитать. Сорри за большую цитату, но думаю что так этот текст прочитает гораздо больше людей и не придётся отвечать на одни и те же вопросы по сто раз.

I'll add to that, the view source and javascript console moving (which wasn't intended to be a feature removal, just a menu item change) was reversed pretty quickly because they didn't fall into brendan's "buggily inadequate, vestigial feature" category and because there was confusion and miscommunication between me and others on the project team including Ben Goodger, the Firefox Owner. I do think that it's an important point though, that there is big difference between removing features and burying UI for those features. We've made the preferences/options window considerably more user friendly by burying literally hundreds of options in either "Advanced" or "about:config". There were lots of people screaming and gnashing teeth (and calling names) as that happened (many still are) but I think it was the right thing to do to make the preferences window at least somewhat useful to a large audience of non-geeks. That UI reorganization didn't remove features, it just lowered the visibility and changed the UI for features. JavaScript Console, the middle three tabs of Page Info, and View Source were intended to be similar changes, lowering the visibility, not removing.

What about other feature removals, actual removals, not just the shifting of UI access points? Should we ship a wholly broken feature and release note that it doesn't work? At what point is it too bad to ship? If it's a dataloss problem then do you pull it? What if half of it works and half of it fails? What if we have no idea whether it works or not? What if it's not technically broken but it's just a really ugly user experience?

Brendan certainly leaves the door open to removing "buggily inadequate, vestigial feature" and I think that's quite important. Stubbornly not removing features this late in the game because people don't think 1.0 should have fewer features than 0.9 leads to real problems. If something is badly broken or means a very poor user experience, should it stay in just because a vocal few are willing to live with that brokenness and because we've been shipping those problems to the current user base for some time? I'm not talking about view source or JS console, neither of which meet the "buggily inadequate" criteria; I'm talking about other major features with menu items and buttons and other prominent UI that simply fail, have really bad bugs, or lead to a terrible user experience and which may not be fixed for 1.0. Do we ship a menuitem like "export bookmarks" that simply doesn't work because our community of users is used to that failure? Do we ship the Bookmarks quick search field even though it leads to about a half dozen serious bugs including the appearance of dataloss? (Hopefully these bookmarks problems will be fixed because right now we've got strong and active owership for Bookmarks, but there are plenty of other examples, some of which will surely not be fixed in time for the release.)

Off-line is a good example. It had major bugs that no one was currently addressing and hadn't addressed for years. An IE user attempting to use our off-line would have a horrible experience compared to what he was used to on IE. Not only the dataloss problems and failures to connect and disconnect from the internet when going off or back online, but simple usability failings like not showing the user what items are actually available offline or disabling the bits that aren't available. It's an all around awful experience for any regular IE off-line user to encounter and no one seemed the least bit interested in fixing it for Firefox. Part of the reason, I'm sure, is that the Mozilla community is just used to this kind of brokenness. We're comfortable with that level of failure and we assume so will be the millions of IE converts we're anticipating in the coming months. We've been using half-implemented features with horrible UI forever, but it was worth it because we had pop-up blocking or tabbed browsing or some other feature that made it easy to overlook the warts.

SO what to do about broken features and what about features that we don't have time to test? Should we be shipping unknowns? There are features that I don't test and that I don't have any idea the state of. There could be major bugs reported in bugzilla even, that are languishing in Unconfirmed or mis-assigned or even correctly assigned but not on the radar of the project team. Is crossing our fingers on these features the right thing to do? If it completely ruined the browsing experience for some segment of users then should we ship it because "you can't pull features after 0.9"?

And what about features that are only somewhat broken? A good example is themes and theme switching. We've never done perfect dynamic theme switching, there's always some cruft left over from the previous theme and we've often had dataloss problems associated with theme switching. Today I installed a fresh Firefox build and created a brand new profile -- like I do pretty much every morning. I went to update.mozilla.org and installed the number 2 most popular theme from update.mozilla.org and not only did I lose all the pages I had in open tabs and windows (including a bugzilla bug I was in the middle of reporting) but after a restart I couldn't get my browser back at all. Something about an XBL error. OK, so that's a bad theme, I guess. Apparently, when something goes horribly wrong with a theme, we don't fail back to the default, we just die. User's are gonna love that one. After blowing away that profile I installed some other themes and found that we don't switch fully on several themes without a restart and some themes lead to a primary toolbar with three or four copies of each button. I also noticed that we add really odd scrollbars to some Web pages and XUL windows (like download manager and the theme manager itself) when you switch themes. Also, at least one of my themes likes to clear out the URLbar when I switch to or from it. Is it "good enough" to ship? Is it an embarrassment? I suspect a that judgement is heavily impacted by whether you've grown accustomed to the broken behavior over the years or whether you're a brand new Firefox user migrating from IE or some other browser that doesn't suffer from such obvious failures. We have other features like Fullscreen which might seem fine to SeaMonkey users who are used to the brokenness but which will be a real shock to IE users. Is it better to leave those in and have a semi-functional but embarrassingly buggy and incomplete feature than to not have the feature at all?

We removed bookmark notification because it was highly buggy and no one was working on making it less buggy. The same for off-line. Was that the wrong move? Do we care that there may be some some highly visbile features will make us look really bad to new converts?

If we can't fix them in time for PR or 1.0, should we ship much loved features like dynamic theme switching (or theme switching at all) because we're all comfortable with that level of bugginess or should they be removed? And what's the reaction going to be when other features simply have to be removed, like the really nice find in page highlighting or the auto-scrolling icon that work by changing the DOM of the page? Will there be crying and gnashing of teeth when those features get pulled?

Brendan was right and I was wrong about JS Console and View Source. We can't touch the primary access points for these features because there are too many people in the Mozilla community that need them and the Mozilla community is one of our most important audiences. If we had more time, maybe we could experiment with changing access points but it's too late in the game to get decent feedback, I suppose.

Оригинал: http://weblogs.mozillazine.org/asa/

А ещё _обязательно_ прочтите вот это: http://weblogs.mozillazine.org/roadmap/archives/006284.html

> насмешил, большинство людей которых это "заботит" пионеры 14-16ти лет, которые то и английского не знаю. Толку им от этого форума?

Дык, в школе тоже английский учат ;)

>>кто-нибудь знает когда пофиксят в Firefox проблему, в адресной строке >>набираеш адрес сайта а он не открывается например вседствии например >>перегруженого канала, а ты в это время ходил по другим табам, и >>Firefox ТЕРЯЕТ ссылку, и приходится вспоминать а куда же ты хотел >>зайти?

Еще есть такая фигня что в строке статуса отображается статус другого таба. Еще скажем открываю таб и переключаюсь в другой таб, в это время первый загружается и у него есть иконка - иконка отображается в текущем а не в том где надо. Киньте это в ввиде багрепорта плиз !

>>Кстати, а кто-нибудь знает, почему у меня firefox на сайтах типа >>http://linux.ru или здесь в оконном режиме постоянно мигает?

Не наблюдается. Обновляйся.