Re: eww/shr: a method for ignoring elements?

Re: eww/shr: a method for ignoring elements?

[Lars Magne Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Some web pages I visit with eww contains stuff that, for several
> reasons, I prefer to ignore. Is there any mechanism in eww or shr for
> not fetching some embedded elements such as images or other content
> based on their URL?

See `shr-blocked-images'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: eww/shr: a method for ignoring elements?

[Óscar Fuentes]

Lars Magne Ingebrigtsen <lmi@gnus.org> writes:

> See `shr-blocked-images'.

Thanks Lars, although that variable affects only images.

My primary use case is related to blocking trackers, javascript-based
commentary sections (disqus, bazaar-voice) and similar stuff. Besides
privacy control, too often eww hangs because the sites which are
contacted by those elements do not respond quickly and it is necessary
to press C-g several times to make eww responsive again.

Re: eww/shr: a method for ignoring elements?

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
>
>> See `shr-blocked-images'.
>
> Thanks Lars, although that variable affects only images.
>
> My primary use case is related to blocking trackers,

What kind?

> javascript-based commentary sections (disqus, bazaar-voice) and
> similar stuff.

shr doesn't do JS...

> Besides privacy control, too often eww hangs because the sites which
> are contacted by those elements do not respond quickly and it is
> necessary to press C-g several times to make eww responsive again.

Images should be loaded asynchronously.  The only synch element should
be the DNS resolution, which we must make asynch one of these days.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: eww/shr: a method for ignoring elements?

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
>>
>>> See `shr-blocked-images'.
>>
>> Thanks Lars, although that variable affects only images.
>>
>> My primary use case is related to blocking trackers,
>
> What kind?

Things like google-analythics and disqus. When one of those do not
respond, for whatever reason, eww just waits for a long time.

This is part of the message sequence of a web page I just visited:

Contacting host: feeds.nature.com:80
Opening TLS connection to ‘disqus.com’...
Opening TLS connection with ‘gnutls-cli --insecure -p 443 disqus.com’...done
Opening TLS connection to ‘disqus.com’...done
Opening TLS connection to ‘a.disquscdn.com’...
Opening TLS connection with ‘gnutls-cli --insecure -p 443 a.disquscdn.com’...done
Opening TLS connection to ‘a.disquscdn.com’...done

If disqus.com responds quickly, there is no problem. But if it is slow
or unresponsive (something that happens a few days every other month)
eww hangs on

Opening TLS connection with ‘gnutls-cli --insecure -p 443 disqus.com’...done

At that point pressing C-g makes the same message reappear (it seems
that eww re-tries the operation) which hangs again. Several C-g's are
required to unblock eww (and Emacs). To make things worse, every now and
then Emacs crashes on that sequence of C-g's. And all this for accessing
a site that provides nil or negative value to the page's content.

>> javascript-based commentary sections (disqus, bazaar-voice) and
>> similar stuff.
>
> shr doesn't do JS...

I know, but the sites are contacted anyways (eww has no way to know that
the content being asked for depends on the availability of JS.)

>> Besides privacy control, too often eww hangs because the sites which
>> are contacted by those elements do not respond quickly and it is
>> necessary to press C-g several times to make eww responsive again.
>
> Images should be loaded asynchronously.  The only synch element should
> be the DNS resolution, which we must make asynch one of these days.

Images is not the worst problem (although moving content around for
showing an image after you begun to read the text is more annoying on a
text-based browser than on a GUI-based one, in my experience, and
implementing a poor-man's version of Ad-Block would be nice too), but
the problem is with eww blocking while it contacts stuff mentioned on
the HTML, see above.

Re: eww/shr: a method for ignoring elements?

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> My primary use case is related to blocking trackers,
>>
>> What kind?
>
> Things like google-analythics and disqus. When one of those do not
> respond, for whatever reason, eww just waits for a long time.

Trackers are either images or Javascript.  shr-blocked-images blocks
images, and shr doesn't do JS.  (Or load JS.)

> This is part of the message sequence of a web page I just visited:
>
> Contacting host: feeds.nature.com:80
> Opening TLS connection to ‘disqus.com’...
> Opening TLS connection with ‘gnutls-cli --insecure -p 443 disqus.com’...done
> Opening TLS connection to ‘disqus.com’...done
> Opening TLS connection to ‘a.disquscdn.com’...
> Opening TLS connection with ‘gnutls-cli --insecure -p 443
> a.disquscdn.com’...done
> Opening TLS connection to ‘a.disquscdn.com’...done

I would guess that it's loading an image from disqus.

> If disqus.com responds quickly, there is no problem. But if it is slow
> or unresponsive (something that happens a few days every other month)
> eww hangs on
>
> Opening TLS connection with ‘gnutls-cli --insecure -p 443 disqus.com’...done
>
> At that point pressing C-g makes the same message reappear (it seems
> that eww re-tries the operation) which hangs again. Several C-g's are
> required to unblock eww (and Emacs). To make things worse, every now and
> then Emacs crashes on that sequence of C-g's. And all this for accessing
> a site that provides nil or negative value to the page's content.

And your Emacs is built without GnuTLS support, which may explain your
hangs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: eww/shr: a method for ignoring elements?

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Trackers are either images or Javascript.  shr-blocked-images blocks
> images, and shr doesn't do JS.  (Or load JS.)
>
>> This is part of the message sequence of a web page I just visited:
>>
>> Contacting host: feeds.nature.com:80
>> Opening TLS connection to ‘disqus.com’...
>> Opening TLS connection with ‘gnutls-cli --insecure -p 443 disqus.com’...done
>> Opening TLS connection to ‘disqus.com’...done
>> Opening TLS connection to ‘a.disquscdn.com’...
>> Opening TLS connection with ‘gnutls-cli --insecure -p 443
>> a.disquscdn.com’...done
>> Opening TLS connection to ‘a.disquscdn.com’...done
>
> I would guess that it's loading an image from disqus.

Well, assigning "disqus\.com" to shr-blocked-images did the trick
indeed, so I'm happy now.

Thank you Lars.

> And your Emacs is built without GnuTLS support, which may explain your
> hangs.

Interesting. Thanks again.

eww/shr: a method for ignoring elements?

[Óscar Fuentes]

Some web pages I visit with eww contains stuff that, for several
reasons, I prefer to ignore. Is there any mechanism in eww or shr for
not fetching some embedded elements such as images or other content
based on their URL?