Support for blocking and opening GET/POST requests in IE with WebExtension

REOPENED
Unassigned

Status

()

Firefox
Extension Compatibility
P5
normal
REOPENED
5 months ago
a day ago

People

(Reporter: hectorz, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 months ago
Online banking in China still depends on IE and ActiveX controls. With the NPAPI support gone, this is an alternative effort to support users to easily finalize a payment after initializing a purchase in Firefox.

It works like visiting such an url in Edge, where the original request is blocked and a message explaining the situation and a button open the request in IE is shown.

A few denpendencies:

Bug 1256122: as a work around, I'm canceling the original request and then loading the interstitial extension page in the same tab, in the onBeforeRequest listener.
Bug 1266012: since we're interrupting users' payment, I think it'd better be easier for them to figure out who's doing it.

One thing I'm not sure, when I first use an hosted interstitial page as work around for bug 1256122, the original POST request will still reach the server and invalidate subsequent same request sent in IE, when I redirect it in the onBeforeRequest listener. This seems to contradict bug 1231512 comment 13, where :mayhemer said "When using redirectTo() from "on-modify-request" the behavior regarding redirect veto has not changed, we still cancel the original channel and prevent the original content to load."

Updated

5 months ago
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1345893
(Reporter)

Comment 2

5 months ago
(In reply to Hector Zhao [:hectorz] from comment #0)
> 
> One thing I'm not sure, when I first use an hosted interstitial page as work
> around for bug 1256122, the original POST request will still reach the
> server and invalidate subsequent same request sent in IE, when I redirect it
> in the onBeforeRequest listener. This seems to contradict bug 1231512
> comment 13, where :mayhemer said "When using redirectTo() from
> "on-modify-request" the behavior regarding redirect veto has not changed, we
> still cancel the original channel and prevent the original content to load."

Sorry I didn't try and found bug 1345893 myself, since it doesn't block my development with my current work around for bug 1256122. I do believe it should be a dependency for this bug, which tracks every desirable change to WebExtension API for our extension.
Status: RESOLVED → REOPENED
Depends on: 1345893
Resolution: DUPLICATE → ---

Updated

5 months ago
No longer blocks: 1296400

Updated

4 months ago
Flags: needinfo?(amckay)

Comment 3

4 months ago
Unfortunately as written this bug isn't actionable for the WebExtensions team, especially because its about IE specifically. I'm moving components so it can remain a blocker, but we won't put it in the WebExtensions triages since we'll be focusing on the bugs mentioned.
Component: WebExtensions: Frontend → Extension Compatibility
Flags: needinfo?(amckay)
Product: Toolkit → Firefox

Comment 4

2 months ago
talked with hector and this is not blocking based on the workaround mentioned below.  marking as P5
Priority: -- → P5
(Reporter)

Updated

a month ago
Depends on: 1379616
You need to log in before you can comment on or make changes to this bug.