Closed Bug 1347022 Opened 7 years ago Closed 7 years ago

With e10s enabled, Form POST sent as GET from window created with chrome.windows.create in a Web Extension

Categories

(Core :: Networking, defect)

51 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1344465

People

(Reporter: scott, Unassigned)

References

Details

(Whiteboard: [necko-active])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

I have a WebExtension that uses chrome.windows.create() to open a window that displays a locally packaged HTML file. In the locally packaged HTML file I have an HTML that has method="post". The action posts to an external URL / another site which then processes the data and displays a small UI.

When I run my extension in a profile with 'browser.tabs.remote.autostart.2' set to true (e10s enabled), Firefox always sends a GET instead of a POST.  When I set it to false and restart (and make no OTHER changes), Firefox correctly sends a POST.

I have created a very simple test plugin here: https://github.com/terescode/simple-web-plugin. The web extension displays a browser action button which, when clicked, creates a new window with a simple form and submit button. Clicking on the submit button should send a POST request but when used from a profile with e10s enabled it always sends a GET.

To reproduce,

1. Clone the GIT repo above.
2. Launch FF with 'browser.tabs.remote.autostart.2' set to true
3. Load the simple test plugin using "Load temporary add-on"
4. Click on the browser action button that appears once loaded
5. In the window that opens, click on the submit button
6. Notice in the network panel that the form request is sent as GET and not POST
7. Now set 'browser.tabs.remote.autostart.2' set to false
8. Restart browser
9. Load the simple test plugin using "Load temporary add-on"
10. Click on the browser action button that appears once loaded
11. In the window that opens, click on the submit button
12. Notice in the network panel that the form request is sent correctly as POST



Actual results:

Form request is sent as GET and not POST


Expected results:

Form request is sent correctly as POST
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

I have tested your issue on latest Firefox release v52.0 and latest Nightly build (Buid ID: 20170316030211) and managed to reproduce it. I have loaded the extension in about:debugging and followed the steps from comment 0. With e10s ON there is a GET request and with e10s OFF a POST request is made.
Blocks: e10s
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
this is probably not a core:networking issue (i.e. whatever the networking caller is generally sets the method), but add a log and I'll confirm and try and route.

goto about:networking and use the logging tab on the left so start/stop logging.
Attached file log.txt-main.9664
Here is the log made from about:networking.
Flags: needinfo?(mcmanus)
thanks for the log. what would the URL of the form be? (to help me find it in the log).
Flags: needinfo?(mcmanus) → needinfo?(scott)
Whiteboard: [necko-active]
@Patrick it should be https://posttestserver.com/post.php
Flags: needinfo?(scott)
Line 28647 of the log shows the following:

2017-03-20 08:38:26.582000 UTC - [Main Thread]: I/nsHttp   GET /post.php HTTP/1.1

I don't have any experience reading these logs though to me that does seem to confirm your suspicion in Comment 2 that it is being sent in by the caller.
Andy, I'm not exactly sure where to route this - so I'm going to start with the web-extension expert. I've looked at it from a core::networking angle and confirmed that the method being requested (which the OP describes as the change in behavior) is indeed GET, so that's not something the networking layer is doing.. can you help find the next step?
Flags: needinfo?(amckay)
Any updates?
Flags: needinfo?(amckay) → needinfo?(kmaglione+bmo)
This has to do with the way we handle navigations to URLs that need to run in a different process from the current page.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kmaglione+bmo)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: