[Firefox] Launching javascript script blocking test fails when launched from New Tab

[gorhill]

The test: http://raymondhill.net/httpsb/httpsb-test-js-1.html

1. Block inline scripts globally
2. Have the above link in New Tab (somehow, not sure how)
3. Click on the thumbnail for the link above
4. Result: inline javascript is not disabled
5. Refresh the page: inline javascript is disabled

I found that at line no. 933 of vapi-background.js, the code is not called when launching from the New Tab. Right above, channel.getProperty() raises an exception.

[Deathamns]

I couldn't reproduce this, or maybe I misunderstood the steps 2-3.

[gorhill]

When launching the test case from a tile in the New Tab page (I blacked-out unrelated stuff), the inline script tags are executable, i.e. the CSP header was not added to the page. If I enter http://raymondhill.net/httpsb/httpsb-test-js-1.html directly in the address bar it works fine, but it never works if launched from the New Tab page:

[Deathamns]

from a tile in the New Tab

That was missing. I can confirm, will look into it.

[Deathamns]

For some reason, shouldLoad in frameModule.js doesn't fire for the main frame if initiated from a tile.
So, the request won't be sent to the background page, http-on-opening-request can't pair the requests, the channel data won't be saved, and http-on-examine-response won't have any data to work with.

[Deathamns]

Although shouldLoad doesn't fire, the http observer do, and the request will be considered as a behind-the-scene request. So, the best we could do for these requests, is to fake their type as main_frame, and set the CSP header.
From the platform independent code only this condition should be removed, the rest of the changes would happen in Firefox related code.

[gorhill]

the platform independent code only this condition should be removed

I could remove the condition, however I would still need to test for http/https, as from the core's perspective it doesn't make sense to inject a CSP header in anything else, isn't?

[Deathamns]

Don't you already test that?

Actually, does if ( vAPI.isNoTabId(tabId) ) have any effect there? I mean, onHeadersReceived is fired only for main_frame and sub_frame, and those types are probably won't be set for non-tab related requests.

[gorhill]

It can happen on Chromium that a normal http request is fired behind-the-scene: "behind-the-scene" !== "tabless"~"type".

Correction: oops, mistake, I meant "behind-the-scene" !== "type".

Edit: example

[Deathamns]

Yes, but the question is that; can a behind-the-scene request have the main_frame or sub_frame types?
Because if no, then onHeadersReceived won't be fired for these requests, and therefore that condition becomes unnecessary.

[gorhill]

I can't be bothered to go spend time to find a case now, but assume that yes, behind-the-scene requests can be of any type.

[Deathamns]

Well, yeah; adding an iframe to the background page of an extension, which would be sub_frame...

[gorhill]

Fixed my mistake above, I meant "type", not "tabless".