Если в письме содержится ссылка, то нажатие на неё ничего не даёт (она не открывается в браузере). При этом в Настройки, Вложенные файлы, Просмотр и редактирование действий никаких действий не наблюдается.
$ rpm -qa | grep thunder thunderbird-3.0-alt1.20090424 Подтверждаю.
*** Bug 19581 has been marked as a duplicate of this bug. ***
Created attachment 3619 [details] mimeTypes.rdf
Не знаю, как вам покажется мое решение, но УМВР вот исправленный файлик mimeTypes.rdf (положить в профиль) не вижу причин, почему его не положить в /usr/lib/thunderbird/defaults/profile
Этот файл копируется только в новые профили. Для старых профилей он не поможет.
Да и причина с URL'ами не в этом.
*** Bug 21059 has been marked as a duplicate of this bug. ***
мне mimeTypes.rdf не помог.. из strace видно, что thunderbird проверяет наличие url_handler.sh, но не запускает его.
(В ответ на комментарий №8) > из strace видно, что thunderbird проверяет наличие url_handler.sh Теперь моднее xdg-open
[user@localhost ~]$ rpm -qa |grep thunder thunderbird-3.0-alt1.20090817 thunderbird-ru-3.0-alt3 [user@localhost ~]$ Приложение файла не меняет поведения ни на грош (точнее отсутствие поведения)
*** Bug 21873 has been marked as a duplicate of this bug. ***
У меня, после обновления до thunderbird-3.0-alt1.20090817 ссылки перестали открываться. При последующим обновлении до thunderbird-3.0-alt1.20090929 -- начали открываться, но только после выдора программы-открывателя в соответствующем диалоге (высвечивается при клике на ссылку "неизвестного" типа).
(thunderbird-3.0-alt1.20090601 (в окружении Desktop 4.1 (KDE)) страдал этой проблемой. Проверю ещё более новые релизы.)
Created attachment 4075 [details] скрин настройки скрин в какой строке надо прописывать броузер
А я припоминаю, что в настройках/дополнительно/редактор настроек/network.protocol-handler.app.http броузер свой прописать надо... И сразу всё заработает.
$ grep network.protocol-handler.app /usr/lib/thunderbird/defaults/pref/all-thunderbird.js pref("network.protocol-handler.app.http", "/usr/bin/url_handler.sh"); pref("network.protocol-handler.app.https", "/usr/bin/url_handler.sh"); pref("network.protocol-handler.app.ftp", "/usr/bin/url_handler.sh");
(В ответ на комментарий №16) > pref("network.protocol-handler.app.ftp", "/usr/bin/url_handler.sh"); Нет. Сейчас правильный открыватель ссылок -- xdg-open
(В ответ на комментарий №17) > (В ответ на комментарий №16) > > pref("network.protocol-handler.app.ftp", "/usr/bin/url_handler.sh"); > Нет. Сейчас правильный открыватель ссылок -- xdg-open Не суть, я про то что эти опции используются. А команда: /usr/bin/url_handler.sh 'http://yandex.ru' нормально открывает браузер.
(В ответ на комментарий №17) > (В ответ на комментарий №16) > > pref("network.protocol-handler.app.ftp", "/usr/bin/url_handler.sh"); > Нет. Сейчас правильный открыватель ссылок -- xdg-open Категорически неверно. В Линукс Юниоре открывался Geany, обрабатывающий text/html. И мне пришлось явно прописывать url_handler.sh для indexhtml.
(В ответ на комментарий №19) > > > pref("network.protocol-handler.app.ftp", "/usr/bin/url_handler.sh"); > > Нет. Сейчас правильный открыватель ссылок -- xdg-open > Категорически неверно. Категорически неверно давать ошибочные высказывания. Неверно открывать ссылки тем, что их открыть не может. Попробуй открыть mailto: nfs:/ или smb:/ при помощи url_handler.sh > В Линукс Юниоре открывался Geany, обрабатывающий text/html. Можно было хотя бы посоветоваться прежде, чем извращаться. Я, например, первый раз об этом слышу. Да и вообще, я не знаю, как ты этого добился. Скорее всего специально. > И мне пришлось явно прописывать url_handler.sh для indexhtml. Для этого не извращаться нужно было, а хотя бы попытаться исправить.
(В ответ на комментарий №20) > > В Линукс Юниоре открывался Geany, обрабатывающий text/html. > Можно было хотя бы посоветоваться прежде, чем извращаться. Я, например, первый > раз об этом слышу. Это касалось исключительно вызова indexhtml из .desktop-файла. В среде GNOME. Какой смысл тебя беспокоить по таким мелочам? Ты же по остальным не помогаешь. Потому и надежды нет. > Да и вообще, я не знаю, как ты этого добился. Скорее всего специально. Нет, просто при тестировании сообщили, что indexhtml из меню не открывается в браузере. Попробуй поставить geany и поймаешь багу. > > И мне пришлось явно прописывать url_handler.sh для indexhtml. > Для этого не извращаться нужно было, а хотя бы попытаться исправить. И как, подскажи, пожалуйста?
(В ответ на комментарий №21) > > Для этого не извращаться нужно было, а хотя бы попытаться исправить. > И как, подскажи, пожалуйста? Нужно сначала понять, как ты этого смог добиться.
(В ответ на комментарий №21) > Нет, просто при тестировании сообщили, что indexhtml из меню не открывается в > браузере. Попробуй поставить geany и поймаешь багу. А-а-а, кажется, понял. Кривой GNOME ?
Дык, его весь нужно так "исправлять". Это и к inode/directory тоже относиться. Тоже чем попало вместо файлового менеджера открывается.
(В ответ на комментарий №23) > (В ответ на комментарий №21) > > Нет, просто при тестировании сообщили, что indexhtml из меню не открывается в > > браузере. Попробуй поставить geany и поймаешь багу. > А-а-а, кажется, понял. Кривой GNOME ? Не. Привязка MIME-типов в наших дистрибутивах: кто последний поставился — того и тапки.
(В ответ на комментарий №25) > Не. Привязка MIME-типов в наших дистрибутивах Не в наших дистрибутивах, а в нашем GNOME
ping?
(В ответ на комментарий №25) > (В ответ на комментарий №23) > > (В ответ на комментарий №21) > > > Нет, просто при тестировании сообщили, что indexhtml из меню не открывается в > > > браузере. Попробуй поставить geany и поймаешь багу. > > А-а-а, кажется, понял. Кривой GNOME ? > Не. Привязка MIME-типов в наших дистрибутивах: кто последний поставился — того > и тапки. /usr/bin/url_handler.sh смотрит в /usr/bin/url_handler.sh там /usr/bin/galeon:PW второй в списке, первый -- /usr/bin/firefox:PW При этом если $HOME определена он также лезет в "$HOME"/.etc/urlview/url_handlers
Created attachment 4669 [details] strace падения firefox С другой стороны, если установлена переменная окружения BROWSER, то запустится браузер, который в ней указан. strаce показывает, что firefox не может загрузить необходимые библиотеки при запуске из под птицы
однако, если в скрипт /usr/bin/url_handler.sh добавить строчку LD_LIBRARY_PATH=, то библиотеки ищутся по стандартным путям и firefox нормально стартует Вывод: надо заставить thunderbird обнулять переменную LD_LIBRARY_PATH перед запуском браузера или переустановить эту переменную так, чтобы не терялись стандартные пути поиска библиотек
Здравствуйте. Ребята, исправление будет включено в дистрибутивы?
(В ответ на комментарий №31) > Здравствуйте. > Ребята, исправление будет включено в дистрибутивы? Как только появится.
Я оставил свой комментарий для оживления темы. Даже не знаю.. Тогда спрошу прямо - когда будет исправление? Ответ будет таким же?
Обнуление LD_LIBRARY_PATH гораздо проще сделать в url_handler.
(В ответ на комментарий №34) > Обнуление LD_LIBRARY_PATH гораздо проще сделать в url_handler. В частном случае вызова url_handler. Во всех остальных возможных получается перекладывание проблемы на пользователя.
(В ответ на комментарий №35) > Во всех остальных возможных получается > перекладывание проблемы на пользователя. Сергей, тогда жду патчей на thunderbird.
(В ответ на комментарий №36) > Сергей, тогда жду патчей на thunderbird. Лучше у мантейнера thunderbird попросить.
(В ответ на комментарий №37) > Лучше у мантейнера thunderbird попросить. Мантейнер сказал, как сделать, чтобы работало сейчас. Если нужно, чтобы решение было концептуально правильно, то оно есть: дождаться окончания портирования thunderbird на xulrunner. Если же нужно "чтобы работало сейчас", то лучше сделать это исправление url_handler.
Нет, это скорее "чтоб работало только так". В других дистрибутивах это наверняка решено.
(В ответ на комментарий №39) > Нет, это скорее "чтоб работало только так". > В других дистрибутивах это наверняка решено. Сергей, legion@, мне кажется, правильное решение предлагает. Повесьте багу на url_handler.
(В ответ на комментарий №40) > Сергей, legion@, мне кажется, правильное решение предлагает. Повесьте багу на > url_handler. Для начала на xdg-open тоже. Если у пользователя в GNOME/KDE настроен умолчательный браузер Cromium etc., то ссылки из Thunderbird должны открываться в нем, независимо от того, какие еще браузеры установлены.
(В ответ на комментарий №41) > (В ответ на комментарий №40) > > Сергей, legion@, мне кажется, правильное решение предлагает. Повесьте багу на > > url_handler. > Для начала на xdg-open тоже. > Если у пользователя в GNOME/KDE настроен умолчательный браузер Cromium etc., то > ссылки из Thunderbird должны открываться в нем, независимо от того, какие еще > браузеры установлены. Ok. Повесили баги?
(В ответ на комментарий №42) > Повесили баги? После прочтения этого обсуждения?
(В ответ на комментарий №38) > Если нужно, чтобы решение > было концептуально правильно, то оно есть: дождаться окончания портирования > thunderbird на xulrunner. Дождались?
(В ответ на комментарий №44) > Дождались? Неа. thunderbird пока не может быть собран с xulrunner: https://bugzilla.mozilla.org/show_bug.cgi?id=306324 Более того, опции network.protocol-handler.app.* больше не работают.
(В ответ на комментарий №45) > (В ответ на комментарий №44) > > Дождались? > > Неа. thunderbird пока не может быть собран с xulrunner: > > https://bugzilla.mozilla.org/show_bug.cgi?id=306324 И занимается этим наш старый знакомый Nobody.
(В ответ на комментарий №46) > И занимается этим наш старый знакомый Nobody. Это всего лишь метабаг. Нужно смотреть на зависимости.
Так как правильное решение скоро не будет, прошу предлагать менее правильные. Есть не более недели на исправление.
(В ответ на комментарий №48) > Так как правильное решение скоро не будет, прошу предлагать менее правильные. > Есть не более недели на исправление. А в thunderbird-5 эта бага воспроизводится ?
(В ответ на комментарий №49) > А в thunderbird-5 эта бага воспроизводится ? Воспроизводится.
(В ответ на комментарий №43) > (В ответ на комментарий №42) > > Повесили баги? > После прочтения этого обсуждения? Да, особенно после прочтения. Бага не только очень древняя, но и очень нехорошая. Лучшего решения мы не дождемся, нужно минимально приемлемое, пусть и временное. И, прошу прощения, asap.
(В ответ на комментарий №51) > Бага не только очень древняя, но и очень нехорошая. Лучшего решения мы не > дождемся, нужно минимально приемлемое, пусть и временное. Наилучшее решение - это кому-нибудь сесть и написать extension, который бы регистрировал необходимые обработчики MIME пользователю. Такое расширение могло бы спрашивать какую-то внешнюю библиотеку о том, что нужно зарегистрировать, либо можно на скорую руку вернуть обработку network.protocol-handler.app.*. Так как системное расширение инициализируется для каждого пользователя, то установка такого расширения исправит всех пользователей.
И ещё, в дистрибутиве вы можете использовать mozplugger с правильными настройками.
(В ответ на комментарий №53) > И ещё, в дистрибутиве вы можете использовать mozplugger с правильными > настройками. Это интересно, но я пока не понимаю, как его настраивать, чтобы он открывал ссылки из tb,
я смотрю, новый thunderbird 5.0 собран с libgio. Действительно ли для него актуален этот баг? проверял ли кто-нибудь? а firefox 5.0.1 собран, кстати, без --enable-gio поэтому как раз для firefox и должны быть актуальны такого рода баги. поскольку, как я понимаю, в новом коде отказались от местных настроек вида pref("network.protocol-handler.app.... в пользу работы с freedesktop mime через gio.
(В ответ на комментарий №55) > я смотрю, новый thunderbird 5.0 собран с libgio. > Действительно ли для него актуален этот баг? > проверял ли кто-нибудь? Да. https://bugzilla.altlinux.org/show_bug.cgi?id=11503#c50 > > а firefox 5.0.1 собран, кстати, без --enable-gio > поэтому как раз для firefox и должны быть актуальны такого рода баги. > поскольку, как я понимаю, в новом коде отказались от местных настроек вида > pref("network.protocol-handler.app.... > в пользу работы с freedesktop mime через gio. FR?
да, действительно. thunderbird по прежнему заносит настройки в mimeTypes.rdf. вроде бы в 6.0 пофикшено, а нам имеет смысл посмотреть в сторону debian patches - debian/patches/default-uri-handler-check-use-gio.patch - debian/patches/default-mailer-check-use-gio.patch
(В ответ на комментарий №56) > > а firefox 5.0.1 собран, кстати, без --enable-gio > > поэтому как раз для firefox и должны быть актуальны такого рода баги. > > поскольку, как я понимаю, в новом коде отказались от местных настроек вида > > pref("network.protocol-handler.app.... > > в пользу работы с freedesktop mime через gio. > FR? https://bugzilla.altlinux.org/show_bug.cgi?id=26136
Внешние обработчики в firefox теперь открываются через libgio (task#52920). В это же задание пойдёт и исправленный thunderbird. Я думаю решение для thunderbird будет таким же как и для firefox.
(В ответ на комментарий №59) > Внешние обработчики в firefox теперь открываются через libgio (task#52920). В > это же задание пойдёт и исправленный thunderbird. Я думаю решение для > thunderbird будет таким же как и для firefox. Алексей, ты можешь расшарить задание, чтобы помочь тебе собрать задание?
(В ответ на комментарий №60) > Алексей, ты можешь расшарить задание, чтобы помочь тебе собрать задание? Разумеется. Сделано.
thunderbird-6.0-alt1 -> sisyphus: * Thu Aug 25 2011 Alexey Gladkov <legion@altlinux> 6.0-alt1 - New version (6.0). - Add GIO support (ALT#11503). - Fixed: + MFSA 2011-31 Security issues addressed in Thunderbird 6
(В ответ на комментарий №62) > thunderbird-6.0-alt1 -> sisyphus: > > * Thu Aug 25 2011 Alexey Gladkov <legion@altlinux> 6.0-alt1 > - New version (6.0). > - Add GIO support (ALT#11503). > - Fixed: > + MFSA 2011-31 Security issues addressed in Thunderbird 6 Ура! Спасибо всем, кто над этим работал и сочувстовал, персонально legion@ и viy@!
(В ответ на комментарий №63) > Ура! > Спасибо всем, кто над этим работал и сочувстовал, персонально legion@ и viy@! Алексей, должен ли я расценивать ваш комментарий как "Я проверил, всё работает" ? :) Дело в том, что для этого релиза мне пришлось пропатчить один из мозилловских модулей, который по умолчанию не работал ... и если всё хорошо, то я хотел бы оформить патч в апстрим.
(В ответ на комментарий №64) > (В ответ на комментарий №63) > > Ура! > > Спасибо всем, кто над этим работал и сочувстовал, персонально legion@ и viy@! > > Алексей, должен ли я расценивать ваш комментарий как "Я проверил, всё работает" > ? :) > > Дело в том, что для этого релиза мне пришлось пропатчить один из мозилловских > модулей, который по умолчанию не работал ... и если всё хорошо, то я хотел бы > оформить патч в апстрим. Пока нет. Сегодня начнем проверять.
Открывает не тем, чем настроено у пользователя. Я же писал, нужно использовать xdg-open.
(В ответ на комментарий №66) > Открывает не тем, чем настроено у пользователя. Я же писал, нужно использовать > xdg-open. Где настроено? Прошу viy@ разъяснить...
(В ответ на комментарий №67) > Где настроено? В той среде, куда libgio не суется. Например, KDE3 и KDE4
В общем, это решается экспортом переменных, но все-равно хреново. Только xdg-open по нормальному открывает.
(В ответ на комментарий №67) > Где настроено? > Прошу viy@ разъяснить... http://www.altlinux.org/Mime_Policy: Что касается настроек, специфических для конкретного DE, то freedesktop-совместимый DE должен хранить свои настройки в /usr/share/<DE>/applications/ и экспортировать этот путь в переменной XDG_DATA_DIRS в своем стартовом скрипте /usr/bin/start<DE>. Сейчас KDE хранит свои настройки в /usr/share/<DE>/applications/, но XDG_DATA_DIRS не экспортирует. Естественно, thunderbird настройки KDE не использует. тем не менее, xdg-open, используя встроенную телепатию, определяет окружение как KDE и явно передает обработку url в KDE. поэтому он продолжает работать корректно и в отсутствие XDG_DATA_DIRS. > В общем, это решается экспортом переменных, вот. > но все-равно хреново. так по стандарту задумано.
(В ответ на комментарий №70) > и экспортировать этот путь в переменной XDG_DATA_DIRS Уже собирается > в своем стартовом скрипте /usr/bin/start<DE>. Проблема в том, что у нас не катит конструкция [ -n "$XDG_DATA_DIRS" ] || export XDG_DATA_DIRS=/some:/dirs из-за /etc/profile.d/shared-mime-info.sh
я в http://www.altlinux.org/Mime_Policy#.D0.9F.D1.80.D0.B8.D0.BE.D1.80.D0.B8.D1.82.D0.B5.D1.82_.D0.BF.D1.80.D0.B8.D0.BB.D0.BE.D0.B6.D0.B5.D0.BD.D0.B8.D0.B9 предлагал XDG_DATA_DIRS=/usr/share/<DE>:${XDG_DATA_DIRS:-/usr/share} export XDG_DATA_DIRS вроде бы рабочее.
а /var/cache, думаю, пора уже выбрасывать из XDG_DATA_DIRS. там должен быть только устаревший генерат.
(В ответ на комментарий №73) > а /var/cache, думаю, пора уже выбрасывать из XDG_DATA_DIRS. Ага
(В ответ на комментарий №72) > XDG_DATA_DIRS=/usr/share/<DE>:${XDG_DATA_DIRS:-/usr/share} Это где? В start<de>? Если часть(имеющая преимущество) установлена в /usr/local , то как? И из shared-mime-info сначала удалить нужно.
(В ответ на комментарий №75) > (В ответ на комментарий №72) > И из shared-mime-info сначала удалить нужно. повесил https://bugzilla.altlinux.org/show_bug.cgi?id=26194 > > XDG_DATA_DIRS=/usr/share/<DE>:${XDG_DATA_DIRS:-/usr/share} > Это где? В start<de>? Да, как я понимаю > Если часть(имеющая преимущество) установлена в /usr/local , то как? не совсем понял, но, думаю, не страшно. /usr/local/share/applications и т.д. не помешает смотреть.
(В ответ на комментарий №76) > /usr/local/share/applications и т.д. не помешает смотреть. Помешает, порядок другой. Единственный вариант я описал в bug 26194
ок.
(В ответ на комментарий №64) > Дело в том, что для этого релиза мне пришлось пропатчить один из мозилловских > модулей, который по умолчанию не работал ... и если всё хорошо, то я хотел бы > оформить патч в апстрим. Протестировали ?
(В ответ на комментарий №79) > Протестировали ? Да, всё отлично работает. Спасибо.
