В профиле есть папка custombuttons и в ней файлы:
buttonsoverlay.xul.bak
buttonsoverlay.xul.cop
buttonsoverlay.xul.sbk
buttonsoverlay.xul1.bak
buttonsoverlay.xul1.sbk
buttonsoverlay.xul2.bak
buttonsoverlay.xul

Подскажите, за что каждый из них отвечает?

Как я понимаю, в этих файлах хранятся настройки и если я захочу перенести свои кнопки на другой профиль, надо туда скопировать эту папку целиком?

Ferguss114 пишет

Как я понимаю, в этих файлах хранятся настройки и если я захочу перенести свои кнопки на другой профиль, надо туда скопировать эту папку целиком?

Наверно хранятся, но я переносил кнопки на другой профиль используя только buttonsoverlay.xul

Спасибо, понятно. Ещё вопрос, хоть и не совсем по Сustom Buttons.
Встречал совет поудалять из  папок locale в расширениях все локали кроме необходимой. Якобы это ускоряет запуск браузера.

Это правда? Или Или уменьшение размера настолько мизерное, что его и не будет заметно?

Ferguss114
Я думаю это запуск браузера не ускорит.

Что за файл в профиле seer.sqlite? У меня он был 47mb. Удалил, перезапустил,  появился новый на 340kb, разницы не заметил.

Тот же вопрос, что и у предыдущего оратора. Упоминания на мозиллалайне есть, но я так и не понял за что этот файл отвечает.

Sagen пишет

что и у предыдущего оратора

Ну это ты мощно задвинул, про оратора. :D

Sagen пишет

Упоминания на мозиллалайне есть, но я так и не понял за что этот файл отвечает.

Я там только нашёл, что он вырастает до 115MB. А вот для чего он, похоже этого пока толком никто не знает :)

У меня нет такого файла, где Вы его взяли?

W@ld_Lii пишет

У меня нет такого файла, где Вы его взяли?

Ты хочешь чтобы с тобой поделились, или как? :)

voqabuhe, а есть чё?

Как я понял, seer.sqlite переименовали в netpredictions.sqlite, но для чего он предназначен так и непонятно.

voqabuhe
С https://bugzilla.mozilla.org/show_bug.cgi?id=917682#c0:

Project/Feature Name: Necko Predictive Network Actions
Tracking  ID:881804
Description:
This project allows us to speed up page load time by "getting the boilerplate out of the way" when we're confident what the boilerplate will be for a page load. This means one or more of: resolving DNS, performing the TCP handshake, and (where applicable) performing the TLS handshake. This has the potential to save 100ms-multiple seconds on a page load, depending on the user's configuration, internet connection, and the page being loaded. We predict in one form or another on the following events:

*Browser startup (what pages does the user usually hit immediately after starting the browser?)
*Pageload (when you load this page, or a page from this domain, what subresources or domains are very likely to be used?)
*User hovers on a link (hovering on that link? you might be thinking about clicking!)

This is inspired by chrome's predictor: http://www.igvita.com/posa/high-perform … #predictor (note that we are not yet implementing "resource prefetching" and "page prerendering" in the table of techniques that chrome currently uses).
Additional Information: