Blocking and redirecting requests with onBeforeRequest doesn't work

RESOLVED DUPLICATE of bug 1163862

Status

defect
RESOLVED DUPLICATE of bug 1163862
4 years ago
Last year

People

(Reporter: maciej.cwiek9, Assigned: mao)

Tracking

44 Branch
Dependency tree / graph
Bug Flags:
blocking-webextensions +

Firefox Tracking Flags

(firefox42 affected, firefox43 affected, firefox44 affected, firefox45 affected)

Details

(Whiteboard: [webRequest])

Attachments

(2 attachments, 1 obsolete attachment)

795 bytes, application/zip
Details
1.96 KB, application/zip
Details
Reporter

Description

4 years ago
Posted file test.xpi (obsolete) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36

Steps to reproduce:

1) Install the attached extension
2) Go to any page other than example.com


Actual results:

The requested page is loaded.


Expected results:

You should get redirected to example.com.

The same extension, when unpacked and loaded up in Chrome works as expected.
Reporter

Updated

4 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1066890#c11 -> Bill McCloskey (:billm)

Bill, can you confirm the bug and look to integrate it into the planing?
Flags: needinfo?(wmccloskey)
OS: Unspecified → All
Hardware: Unspecified → All
See Also: → 1201979
The .xpi file seems broken. It contains a manifest.json file and another xpi (which itself contains a manifest.json file). Can you upload the correct test add-on?
Flags: needinfo?(wmccloskey) → needinfo?(maciej.cwiek)
Reporter

Comment 3

4 years ago
Posted file test-working.xpi
Attachment #8687209 - Attachment is obsolete: true
Flags: needinfo?(maciej.cwiek)
Ah, I see. Right now we don't support redirection from onBeforeRequest. If you need a workaround, could you do the redirect from onBeforeSendHeaders instead?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [webRequest]
Reporter

Comment 5

4 years ago
(In reply to Bill McCloskey (:billm) from comment #4)
> Ah, I see. Right now we don't support redirection from onBeforeRequest. If
> you need a workaround, could you do the redirect from onBeforeSendHeaders
> instead?

Since onBeforeSendHeaders also has request blocking capability, it could be an option for a workaround. We'll give it a try.
Reporter

Comment 6

4 years ago
(In reply to Bill McCloskey (:billm) from comment #4)
> Ah, I see. Right now we don't support redirection from onBeforeRequest. If
> you need a workaround, could you do the redirect from onBeforeSendHeaders
> instead?

I wasn't entirely right as in fact onBeforeSendHeaders is not able to redirect to a different URL.
However onHeadersReceived can, but there seems to be identical problem there as for onBeforeRequest - returning an object from the handler with redirectUrl property doesn't cause triggering the redirection. I've attached an xpi utilising onHeadersReceived, if you'd like to take a look.
Reporter

Comment 7

4 years ago
Flags: needinfo?(wmccloskey)

Updated

4 years ago
Assignee: nobody → g.maone
Iteration: --- → 45.3 - Dec 14
(In reply to Maciej Ćwiek from comment #6)
> (In reply to Bill McCloskey (:billm) from comment #4)
> > Ah, I see. Right now we don't support redirection from onBeforeRequest. If
> > you need a workaround, could you do the redirect from onBeforeSendHeaders
> > instead?
> 
> I wasn't entirely right as in fact onBeforeSendHeaders is not able to
> redirect to a different URL.
> However onHeadersReceived can, but there seems to be identical problem there
> as for onBeforeRequest - returning an object from the handler with
> redirectUrl property doesn't cause triggering the redirection. I've attached
> an xpi utilising onHeadersReceived, if you'd like to take a look.

I'm not sure I understand what you mean here. It sounds like you need a single handler that can both block requests and redirect? If that's true, then there is no workaround. We'll need to wait until this bug is fixed.
Flags: needinfo?(wmccloskey)

Comment 9

4 years ago
What I can confirm is that in the onBeforeRequest a request can be canceled, curiously this doesn't seem to work when a search is initiated from the omnibar.

In onBeforeSendHeaders I was able to correctly redirect a request.
Assignee

Updated

4 years ago
Iteration: 45.3 - Dec 14 → 46.1 - Dec 28
Assignee

Updated

4 years ago
Iteration: 46.1 - Dec 28 → 46.2 - Jan 11

Updated

4 years ago
Iteration: 46.2 - Jan 11 → 46.3 - Jan 25
Assignee

Updated

4 years ago
Iteration: 46.3 - Jan 25 → 47.1 - Feb 8
Depends on: 1163862

Comment 10

4 years ago
Would it be possible to have this available when e10s hits with version 46?
Assignee

Comment 11

4 years ago
(In reply to Markus Hartung from comment #10)
> Would it be possible to have this available when e10s hits with version 46?

My understanding is that current goal is enabling e10s for "50% of the population who do not have add-ons installed or a11y features enabled for Firefox 46", see https://wiki.mozilla.org/E10s/Status/Jan15#Release_Schedule

That said, I'm sure this will be available well before e10s gets enabled for add-ons users in stable Firefox releases.

Updated

3 years ago
Flags: blocking-webextensions+
Assignee

Updated

3 years ago
Iteration: 47.1 - Feb 8 → 47.2 - Feb 22
Assignee

Updated

3 years ago
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1163862

Updated

Last year
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.