IMfO.ru

All God’s chillun got shoes

ILO: currentURI.spec

Решил посмотреть как ILO работает в ночных сборках Firefox. Как оказалось, достаточно было переписать пару моментов и всё заработало, однако… Иногда у меня возникает чувство, что в MoFo есть некий доброволец, специально ставящий палки в колёса этого расширения. Фанат Оперы, наверное.

Загрузкой элементов рулит метод shouldLoad интерфейса nsIContentPolicy, о котором я уже немного писал. Если бы при отработке запроса можно было бы просто вернуть true или false, всё было бы чудесно, но, жизнь была бы скучна, не так ли (ух, как много «бы»)? Скажем, когда при отключенных картинках в «голом» Firefox у вас исчезают отступы тредов в ЖЖ, или вы видите инлайн-текст alt’ов, или чувствуете, что «где-то здесь должна быть картинка», а её нет, то это как раз результат возврата false. Отрисовка, которая учитывала бы указанные размеры изображения, не производится. Для борьбы с таким поведением в своё время пришлось поломать голову и я пришёл к достаточно замороченой логике, в основе которой лежит подмена/обнуление contentLocation.spec. Если графический элемент был заблокирован, то этот самый spec у него будет null. src же остаётся на месте, его не трогаем.

Качаю trunk, ставлю ILO, загружаю страницу, контекстное меню на заблокированных картинках появляется без пунктов «Load image», «View image» и т.д. Лезу в код, смотрю отличия:

Windows; en-US; rv:1.7.7; Gecko/20050414 Firefox/1.0.3
Prototype for nsContextMenu (browser.js, line 3592):

// See if the user clicked on an image.
if ( this.target.nodeType == Node.ELEMENT_NODE ) {
     if ( this.target.localName.toUpperCase() == "IMG" ) {
        this.onImage = true;
        this.imageURL = this.target.src;

Windows; en-US; rv:1.8b2; Gecko/20050505 Firefox/1.0+
Prototype for nsContextMenu (browser.js, line 3790):

// See if the user clicked on an image.
if ( this.target.nodeType == Node.ELEMENT_NODE ) {
     if ( this.target instanceof Components.interfaces.nsIImageLoadingContent &&
          this.target.currentURI != null ) {
        this.onImage = true;
        this.imageURL = this.target.currentURI.spec;

Мне не остаётся ничего другого, кроме как сделать

eval('nsContextMenu.prototype.setTarget = ' +
        nsContextMenu.prototype.setTarget.toString()
            .replace(/this\.target\.currentURI(\.spec)?/g, 'this.target.src'));

, скрестить пальцы, надеяться на то, что такое заигрывание с браузером не проявит себя где-нибудь потом в не самом лучшем виде, и параллельно искать альтернативный путь вклинивания в отрисовку блокируемых элементов.

PS. Интересно, с чем я столкнусь в следующих сборках?

PPS. Кстати, советую пока что воздержаться от скачивания последних транков, во всяком случае, под Windows. Сборка 20050430 вроде как нормально работает, а вот вчерашняя 20050505 — не очень.

Categories: dHtml | comments: (8)

Комментарии

Комментарии временно отключены.