Opened 5 years ago

Last modified 19 months ago

#11671 new defect

HTTPS Everywhere breaks http://www.theregister.co.uk/

Reported by: cypherpunks Owned by: zyan
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The page loads but all styling is missing. Like a trip back to the 1990s!

The JS console shows "loadContext is null" at https-everywhere.js:424 each time

This occurs in both 3.5.1 and 4.0dev16. All is normal when HTTPSE is disabled

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 5 years ago by cypherpunks

This is in Firefox 29

comment:2 Changed 5 years ago by cypherpunks

The problem is also there in SeaMonkey 2.26.1 which is based on Firefox 29.

The null loadContext causes an exception which then causes Firefox to stop processing the Javascript with the problem. In turn this causes the CSS not to be loaded. I've not investigated in detail, but handling the null pointer appears to fix the problem. Here's a proposed fix (note that I don't have access to diff on this Windows box so I've annotated the code by hand):

  getWindowForChannel: function(channel) {
    // Obtain an nsIDOMWindow from a channel
    let loadContext;
    try {
      loadContext = channel.notificationCallbacks.getInterface(CI.nsILoadContext);
    } catch(e) {
      try {
        loadContext = channel.loadGroup.notificationCallbacks.getInterface(CI.nsILoadContext);
      } catch(e) {
        this.log(NOTE, "No loadContext for " + channel.URI.spec);
        return null;
      }
    }

    /* vvvvvvvvvvv new code starts here vvvvvvvvvv */
    if (!loadContext) {
      this.log(NOTE, "loadContext is null for " + channel.URI.spec);
      return null;
    }
    /* ^^^^^^^^^^ new code ends here ^^^^^^^^^^ */

    /* The following is line 424 that can't deal with loadContext being null */
    let domWin = loadContext.associatedWindow;
    if (!domWin) {
      this.log(NOTE, "failed to get DOMWin for " + channel.URI.spec);
      return null;
    }

    domWin = domWin.top;
    return domWin;
  },

Editing c:\Users\xxx\AppData\Roaming\Mozilla\...\Profiles\xxxx.default\extensions\https-everywhere@…\components\https-everywhere.js by hand directly in my installation fixes the problem. That's the limit of the testing I've been able to do.

I don't know how we get a null loadContext without triggering one of the earlier exceptions. I don't know if that's a bug in Firefox but, in any event, some defensive programming is probably warranted in any security product.

In case it helps debug the problem, I'll note that, at the time of writing, www.theregister.co.uk includes CSS with the line:

<link rel=stylesheet type="text/css" href="/style_picker/design?e">

However, that's not where it ends up. The server provides a 302 Found response that redirects the browser (presumably just Gecko based browsers) to http://www.theregister.co.uk/Design/style/design/gecko.css?e

I have a feeling that this problem affects just some systems where I have SeaMonkey installed whereas others are fine. This, in turn, suggests that there some other factor that interacts to cause the problem such as which plugins are installed or similar.

comment:3 Changed 5 years ago by cypherpunks

This, in turn, suggests that there some other factor that interacts to cause the problem such as which plugins are installed or similar.

Indeed this was the case only it was extensions rather than plugins:

  • All extensions enabled: bug present.
  • All extensions disabled: bug not present.
  • All extensions enabled except HTTPS Everywhere: bug not present
  • All extensions (including HTTPS Everywhere) enabled except FoxyProxy: bug not present
  • Just HTTPS everywhere and FoxyProxy enabled, all other extensions disabled: bug present

So, it's the combination of HTTPS Everywhere (3.5.3) and FoxyProxy (4.2.4) that causes the problem.

Since I don't have FoxyProxy installed on any of my other SeaMonkey installations, this explains why this was the only machine affected.

comment:4 Changed 5 years ago by cypherpunks

So, it's the combination of HTTPS Everywhere (3.5.3) and FoxyProxy (4.2.4) that causes the problem.

To forestall the next question: FoxyProxy was in an inactive mode where it was told to use the default proxy settings for all links. My default proxy settings are no proxy.

comment:5 Changed 19 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.