У меня в цепочке окошек, которая показывается в процессе создания новой учётки, есть одна, где нужно ввести имя почтового сервера и имя пользователя на нём.

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

Или можно вместо имени сервера вписать его IP-адрес.

(Мне во время некоторых прошлых экспериментов было проще - я с одним и тем же ящиком работал одновременно двумя программами - Seamonkey и его клоном Iceape. У TB тоже клон есть - Icedove.)

Сочинение кода (точнее, выбор способа) изменения внешнего вида таблицы было отложено на самый-самый конец. Причина вот какая:

По команде открытия окна истории открывается history.xul, в котором элемент <tree> задан с жёстким перечнем столбцов. К history.xul через chrome.manifest прицеплен my.xul, стартовый код которого должен сделать что-то такое, от чего на экране будет <tree> с ещё одним дополнительным столбцом. Но ведь стартовый код history.xul уже отработал и история показана! И что, всю её удалять и выводить заново (как делает вчерашний код "красящий красным")? Не хочется.

А сделать что-либо с xul-ом до того, как окно открыто, невозможно. Значит, нужно или менять команду, открывающую окно истории, чтобы она сразу my.xul открывала, а в my.xul затащить всё содержимое history.xul (так себе решение), или заранее подменять методы класса, отвечающего за работу с этим <tree>.

Имен

Так я же не почтовый адрес поменять предложил, а создать в программе ещё один ящик для того же адреса. А чтобы новый и старый одновременно за одними и теми же письмами не лазили и другу другу не мешали - отключить автоматическое забирание писем старым.

"По условиям задачи" почтовый сервер - IMAP. Значит, все созданные пользователем папки имеются на нём, и при создании нового ящика структура этих папок воспроизведётся автоматически.

Про перенос фильтров только ничего сказать не могу. У меня всегда почта хранилась в формате по умолчанию - "файл на папку". В этом случае фильтры хранятся в файле msgFilterRules.dat и переносятся простым копированием. А куда программа их засовывает при формате "файл на письмо" я не знаю. Но предполагаю, что туда же.

Впрочем, это же предложено только как эксперимент - посмотреть, что получится.
Да и

Thunderbird может хранить письма почтового ящика в одном из двух форматов: "каждая папка в отдельном файле" или "каждое письмо в отдельном файле". Задаётся это в настройках почтового ящика при его создании. По умолчанию - файл на папку. А формат этого файла тупой до безобразия: файл текстовый и все письма лежат в нём подряд, без каких-либо специальных разделителей, одно письмо от другого отделяется лишь пустой строкой. То есть, файл получается устроенным так: заголовок первого письма, тело первого письма, пустая строка, заголовок второго письма, тело второго письма, пустая строка, заголовок третьего письма и т.д.

Рядом с этим файлом лежит ещё один - индексный. Вот он очень (просто нечеловечески) сложно устроен, но зато содержит указания, где именно в главном файле лежит то или иное письмо.

Иногда эти указатели сбиваются и начинают указывать не туда.

А процедура ремонта папки (т.е. создания нового индексного файла) тоже проста до безобразия - она использует только тот факт, что ме

Ну так:
Добавить столбец в окошко таблицы на экране - раз плюнуть.
Данные хранятся в файле .sqlite, значит добываются они оттуда с помощью SQL-запроса. Запрос, который будет возвращать нужные для нового столбца данные, сформировать тоже труда не составляет.

Таково было первоначальное представление - до того, как внутрь полез.

Если нужно, код я изображу. Просто у меня есть изрядный опыт работы с элементом <tree>, и поэтому вопросов по визуальной части затеи не предвидится, все изыскания - как бы данные, получаемые из places, так оформить, чтобы их было удобно в этот элемент засунуть.

А несколько способов добавить столбец в таблицу вот (без оглядки на то, насколько тот или иной применим в данном случае):

1. У <tree> (таблицы) есть дочерний элемент <treecols> (шапка), а у <treecols> есть метод appendChild(), позволяющий

Ну вот, собрался с силами и попытаюсь описать, в чём состояла затея и до чего я докатился.

Вот это безобразие и хочется устранить.

[spoiler=Да чего там делать-то?]Желание же самое простое: добавить в таблицу, где история отображается, ещё один столбец, в котором как-нибудь (да хоть просто плюсиком) будет обозначаться наличие посещённой страницы в закладках.

И реализация представлялась несложной. Есть XUL окна (chrome://communicator/content

А пароль в любом случае отправляется молча, без дополнительных подтверждений.
Вопрос был задан о совершенно другой ситуации - невозможности показать страницу без повторного отправления запроса с введёнными пользователем данными.  Обычно такое происходит, когда по истории посещений назад возвращаешься.

А я напишу. Всю историю - от первоначальной задумки до той ситуации, до которой я сейчас "докатился". Но чуть позже - чтобы это отдельным сообщением было.

Да уж... Ну и где логика (разработчиков)? (На всякий случай: это я сейчас в Iceape сижу, но используемый places.sqlite унаследован от Seamonkey, и записи в нём копились лет 20. А эти "обнулённые" и очень старые нашлись, и совсем свежие, буквально позавчерашние.)

Ну ладно, это ещё как-то понять можно - фактически страницу не посещали.
Но сбрасывать в 0 счётчик при сохранении в файл текущей страницы???

Но теперь мне надо эту новость обдумать и поизучать ситуацию самому.

А пока об

T0PMØ3iLLA
Они ж в SQL-ной базе данных хранятся. А это как MFT у NTFS: когда много записей добавляется - растёт; когда записи удаляются - не уменьшается.

Операция уменьшения ("vacuum") в браузере есть, но, по-моему, она там только вручную запускается.
Впрочем, браузеров развелось много разных, за всеми не уследишь.

Ну, и минимальный размер у некоторых из этих файлов совсем не маленький. Даже у абсолютно пустых, свежесозданных.

(У меня всю жизнь в настройках политика обращения с куками - "удалять по завершении сеанса". А у файла cookies.sqlite размер сейчас полмегабайта. Но это же не значит, что в нём столько хранится. С точки зрения движка SQLite он практически пустой.)

Недовольный
Файл places.sqlite в профиле.