iDev.Pi
Не пытайтесь прятать флеш с помощью EHH - если надо убрать, то блокируйте, а не прячьте. EHH никак не может предотвратить обработку кликов плагинами, они работают "вне браузера".

Я ведь сказал - Adblock Plus не может правильно определить, является ли картинка фоновой картинкой. Как в этом контексте поможет ваше предложение?

iDev.Pi
Владимир имеет в виду то, что Адблок не всегда делает это правильно. Сейчас иногда я встречаю ситуации когда картинка одновременно и image, и background. Такая картинка присутствует в списке дважды и если не заблокировать обе, то одна из них обязательно загрузится.

Владимиp Палант
Может просто если есть два объекта с одинаковым путём, но разного типа, то по-умолчанию блокировать оба если явно не указано обратное?
Вообще я думал, что тип background выставляется самим фоксом, а это, оказывается, фишка АдБлока?

Добавлено 01-06-2010 23:47:12
Кстати, проблема с ABP:EHH.
Вот сайт с примером: http://razgovor.org/
Если прокрутить в самый низ страницы, то внизу будет тонкая строчка с рекламой. Когда я пытаюсь её выделить, то выскакивает горизонтальный скроллбар, который полностью перекрывает всю строчку и я не могу по ней клацнуть.
Возможно ли как-то избавиться от появления скролла?

Добавлено 01-06-2010 23:48:53
...хотя, судя по коду, EHH мне всё равно не поможет в данном случае.

Отредактировано Lain_13 (01-06-2010 23:36:35)

Владимиp Палант
Ок, я эту проблему часто встречал, но так с ходу не вспомню где. Встречу снова — сообщу.

Проблема с ручным обновлением подписки. Когда нажимаю обновление подписки на сервер проходит запрос изменилась ли она и если приходит отлуп "304 Not Modified", то подписка не обновляется. При этом если я в самом браузере открою подписку и нажму Ctrl+F5  (принудительное обновление), то самая последняя версия скачивается... правда АдБлок всё равно получает отлуп 304 даже после этого и подписку не обновляет. Можно ли задействовать механизм принудительного обновления вместо обычного обновления если пользователь сам его инициировал? Естественно автоматическое обновление лучше оставить как есть.
Меня эта проблема с обновлением уже замучала. Хочется проверить работоспособность правил после добавления их в подписку, а она не желает обновляться. Не помогает даже удаление и повторна установка — ставится закешированная в браузере версия. С этим, конечно, можно бороться принудительно убивая кэш, но слишком часто мне это приходится делать и обычно даже это не помогает. Приходится ждать пока оно даст обновит. Тогда как в самом браузере, как я уже сказал выше, подписка по Ctrl+F5 обновляется без проблем и показывает самые последние изменения.

Отредактировано Lain_13 (02-06-2010 11:37:52)

Владимиp Палант
Да я сам ни как не могу понять что не так.

А новые версии файла это просто ссылка на последнюю версию в SVN, возможно она вообще без даты отдаётся. Попробую проверить.

http://ruadlist.googlecode.com/svn/trunk/adblock.txt

GET http://ruadlist.googlecode.com/svn/trunk/adblock.txt HTTP/1.1
Host: ruadlist.googlecode.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100601 Minefield/3.7a5pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
If-Modified-Since: Wed, 02 Jun 2010 07:18:37 GMT

HTTP/1.1 304 Not Modified
Date: Wed, 02 Jun 2010 07:52:46 GMT
Expires: Wed, 02 Jun 2010 07:53:46 GMT
Age: 5
Etag: "1448//trunk/adblock.txt"
Server: GFE/2.0
Connection: keep-alive
Last-Modified: Wed, 02 Jun 2010 07:53:01 GMT

Отредактировано Lain_13 (02-06-2010 12:01:34)

Владимиp Палант
Скорее всего фирменный прокси пакостит. У меня локальный есть, но отсебятина приходит не зависимо от того активен он или соединение идёт на прямую.

Добавлено 02-06-2010 13:57:50
Добавил редирект на https. Теперь всё работает. Спасибо за идею.

Отредактировано Lain_13 (02-06-2010 13:58:41)

Владимиp Палант
Кстати, меня всегда удивляло почему на сайте в меню сверху нет ссылки на страницу с подписками?

Lain_13
Кстати, а что с ruadlist.baywords.com? У меня "unable to connect" и уже давно. Он еще заработает или лучше убрать ссылку?

Это скорее по ключевой фразе "support ticket software". Но ничего конкретного я не знаю.

Отредактировано Владимиp Палант (02-06-2010 19:00:49)

Владимиp Палант
Я думаю я далеко не первый с такой идеей, но что ты думаешь по поводу управляющего комментария вида:

! Include as section name: path_to_file (любой не обязательный текст с описанием)

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

Т.е. это позволит разбивать подписку на отдельные модули которые можно держать в отдельных файлах и обновлять по отдельности в ситуациях когда нет собственного сервера на котором можно указать самому как объединять правила.

Есть где почитать обсуждение на данную тему?

Добавлено 03-06-2010 11:33:50
Кстати, vladmir прав, в окошке информации о странице на закладке с элементами страницы у картинок указывается тип. У одних картинок это image, а у других — background. Т.е. похоже, что код определения типа картинки можно вообще благополучно выпилить и воспользоваться типом, который устанавливает сам браузер.

Добавлено 03-06-2010 11:40:24
Что интересно: на том же tfile.ru, о котором я уже говорил ранее, сейчас отдельные картинки проскакивают в списке дважды с указанием как одного, так и другого типа. При этом в списке элементов страницы они присутствуют лишь в единственном экземпляре и там тип указан лишь один из двух.

Добавлено 03-06-2010 11:58:53
Кстати, что ты думаешь об этом: http://forum.mozilla-russia.org/viewtop … 94#p427494

vladmir
Владимиp Палант

Вот то, о чём я говорю

Страница http://tfile.ru/

Отредактировано Lain_13 (03-06-2010 13:16:01)

vladmir
"Окошко инфы о странице" собирает данные из другого источника - обыскивает страницу в поиске ссылок. Это подход медленный и ненадежный (не всё можно найти таким образом). Adblock Plus получает данные непосредственно от браузера перед загрузкой чего-либо. Это более надежно, но имеет недостаток, что определить наверняка тип картинки невозможно. Если раньше "обычные" картинки хотя бы были привязаны к какому-нибудь элементу <img>, то теперь они часто загружаются задолго до того, как будет создан этот элемент (то самое speculative loading).

Lain_13
Я бы предпочел, чтобы подобные "подсекции" реализовывались с серверной стороны, EasyList уже давно именно так и работает (см. к примеру https://hg.adblockplus.org/easylist/fil … sylist.txt). Думаю, что так оно в конечном счете проще для всех. Скрипт, который "собирает" окончательный вариант подписки, не сильно сложный - могу прислать (Perl, правда, далеко не всем нравится). У меня он работает непосредственно на сервере, где расположен репозиторий, но на самом деле его можно было бы с небольшими изменениями выполнять где угодно - скрипт делает svn checkout, собирает adblock.txt из adblock.txt.template, добавляет комментарий с проверочной суммой и делает svn commit. Если есть компьютер, с которого можно было бы это делать к примеру раз в час, то никаких проблем.

Кстати, "двоятся" картинки из-за того самого speculative loading (этот механизм появился в Firefox 3.6 и существенно ускоряет загрузку некоторых страниц, в SeaMonkey он появится только в версии 2.1). Adblock Plus получает два запроса - сначала на стадии speculative loading, когда элемента <img> еще нет (интерпретируется как background). Потом, когда картинка на самом деле уже загрузилась, с элементом <img> (интерпретируется как image) - "блокирование" на этой стадии уже не может предотвратить запрос, но картинка не покажется. Так что вы сами привели пример проблемы, из-за которой я избавляюсь от типа background - в вашем случае картинки на tfile.ru заблокированы не были, запрос прошел, хоть браузер и не обработал результат.

Добавлено 04-06-2010 10:44:01
Lain_13
По поводу дискуссии с fanboy'ем - в чем вопрос, собственно? В том, лучше ли перечислять все домены в одном правиле или лучше создавать отдельное правило для каждого домена? В основном это вопрос вкуса, после запуска браузера разницы уже нет. Но запуск будет немного быстрее, если правил, которые Adblock Plus должен прочитать из patterns.ini, меньше. И CSS-код в первом случае получается более компактный - думаю, что браузер его отрабатывает немного быстрее.

Отредактировано Владимиp Палант (04-06-2010 10:38:21)

vladmir
Как сказать... Визуально отметить такие элементы в списке можно. Но это будут не только фоновые картинки, но и к примеру xml-запросы, а также элементы, которые были уже удалены из документа. То есть - запрос был, но ни к какому конкретному элементу страницы он не привязан. Возможно, что как-то показывать это было бы полезно. Визуально может быть более бледный шрифт подойдет.