[HTTPS-Everywhere] Please help test an async branch

Jacob Hoffman-Andrews jsha at eff.org
Mon Jan 11 19:18:26 PST 2016


Interesting. I tried to reproduce this, and failed.

I've created a pull request for this branch:
https://github.com/EFForg/https-everywhere/pull/3852

On 12/28/2015 07:03 AM, Claudio Moretti wrote:
> Uhm, actually, as soon as I hit "send" I went on Facebook (which I
> didn't check earlier).
>
> All the background content (scripts/CSS) did not load. Upon
> refreshing, it did (and the page loaded fine).
>
> I closed and reopened Iceweasel: same thing happened again.
>
> Let me know if you'd like me to test something else,
>
> Claudio
>
> On Mon, Dec 28, 2015 at 3:59 PM, Claudio Moretti
> <flyingstar16 at gmail.com <mailto:flyingstar16 at gmail.com>> wrote:
>
>     Hi Jacob,
>
>     I've played with this for ~10 minutes, and it didn't do anything
>     bad to me :)
>
>     I've browsed a few "known" websites, and a few "unknown", with and
>     without rules; it looks fast (which is good) and didn't crash or
>     hang anything (which is even better).
>
>     Is there any specific tests you'd like me to run? I'm using my
>     (very) old laptop (core2duo T7300 at 2.00GHz, 2GB RAM, Debian Jessie,
>     iceweasel 31.3.0esr-1); I'm not going to have access to my "good"
>     laptop until mid-January...
>
>     Thanks!
>
>     Claudio
>
>     On Mon, Dec 28, 2015 at 3:13 AM, Jacob Hoffman-Andrews
>     <jsha at eff.org <mailto:jsha at eff.org>> wrote:
>
>         Hi all,
>
>         The Firefox version of HTTPSE reads its rulesets from a sqlite
>         file and
>         caches them in memory. The current version does this read
>         synchornously
>         the first time a given ruleset is encountered, which has the
>         potential
>         to lock up the UI thread when disk is slow.
>
>         I've got a branch going that switches to reading
>         asynchronously from
>         SQLite. To make it work I had to borrow a subtle hack from
>         AdBlock Plus:
>         If we get a request and we don't yet have the information
>         about what to
>         do with it, we redirect the request to its own URL, then
>         suspend it.
>         Once we get back data from SQLite, we result the request. The
>         redirect
>         handler fires a second time, but now we have the data cached
>         and can
>         rewrite immediately. It's a pretty tricksy change, so I'd like
>         some help
>         testing it out. Branch is here:
>
>         https://github.com/EFForg/https-everywhere/compare/async?expand=1
>
>         Package for testing is here, along with a signature:
>
>         https://jacob.hoffman-andrews.com/https-everywhere-5.1.3asyncbeta-eff.xpi.html
>
>         Thanks,
>         Jacob
>         _______________________________________________
>         HTTPS-Everywhere mailing list
>         HTTPS-Everywhere at lists.eff.org
>         <mailto:HTTPS-Everywhere at lists.eff.org>
>         https://lists.eff.org/mailman/listinfo/https-everywhere
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20160111/17ae67aa/attachment.html>


More information about the HTTPS-Everywhere mailing list