Behind-the-scenes menu not accessible in Opera

[Landpaddle]

Steps to reproduce:

1.) Open Opera.
2.) Navigate to HTTP Switchboard's option menu.
3.) Click on the HTTP Switchboard toolbar icon.

What happened:

The menu is grayed out on page load and remains gray. Clicking the icon yields a blank dialogue, save for the options, wiki, and on/off buttons on the top right.

[gorhill]

This is the expected behavior for when there is no behind-the-scene net traffic. As soon as behind-the-scene net requests are seen, the matrix will be rendered with recorded net requests.

I used to have a "No net traffic seen for this tab" a long time ago. I will put it back.

[Landpaddle]

One note:

Behind-the-scene requests must be blocked by default in Opera. When navigating to Discover with HTTPSB, no content loads, whereas turning the extension off allows content to load again.

This is a bug for Opera users, since it might unwittingly block them from updating extensions or their browser unless they navigate to scoped rules and change the 'Behind-the-scene scope' to not blacklist all.

[gorhill]

Behind-the-scene requests must be blocked by default in Opera

I think you meant "must not be blocked by default"?

By default, behind-the-scene requests are all allowed. However, I did find a bug today, affecting only Opera, which side-effect I believe could have prevented the "whitelist-all" rule to be added to the behind-the-scene scope when the extension was first installed. It is fixed in 0.8.1.2.

A work-around for version 0.8.1.1 or earlier is to go to Scoped rules page, export all rules to a file, click "Reset to factory" and import back the rules saved earlier.

[Landpaddle]

Alright, thank you for the quick responses.

[Landpaddle]

Upon further investigation, it looks like Opera is still denying all behind-the-scene requests by default with HTTPSB 0.8.2.0.

Screenshot of the behind-the-scene scope attached. It loads both deny-all and allow-all scopes, causing updates of extensions, the browser itself, and discover-tab content to fail.

[gorhill]

Whitelist has priority over blacklist (because HTTPSB works in block-all by default ultimately) , so requests shoudn't be blocked with the above rules. You can confirm they aren't blocked by looking at the request log in the Statistics tab, select "Chromium: Behind-the-scene" entry in the drop-down list.

[gorhill]

Ok, found the problem: Opera is creating an "internal" web page, which has the following characteristics:

• A URL address which is not handled by HTTP Switchboard: opera://startpage/.
• Uses a valid tab id, which means requests aren't categorized as being behind-the-scene.
• HTTP requests made by this internal web page go through chrome.webRequest API, which means they are visible to extensions.

So roughly, an internal web page, sitting in a normal tab, and composed of one or more <iframe> from which normal HTTP requests are made.

I need to to think about what is the best solution for this, and something futureproof if ever these internal web pages becomes more common in the future.

[gorhill]

Alright, the chosen fix is to move all "orphan" requests to the behind-the-scene scope. So the behind-the-scene scope will now handle:

• Tabless HTTP requests, i.e. requests which can't be bound to a specific tab (just as before);
• Orphan HTTP requests, i.e. requests which originate from a tab, but the URL of the tab cannot be managed by HTTP Switchboard (opera://startpage in the current case);

The current behavior is that orphan HTTP requests are evaluated against the global scope, and are not reported in the request log. Now these orphan HTTP requests will be evaluated against the behind-the-scene scope, and properly reported in the request log.