WebExtension form POST sent as GET from window created with chrome.windows.create

(Dewittski) #1


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 load in my WebExtension from my every-day FF profile using “Load temporary add-on” everything works great. The signed copy of my extension installed in my users’ browsers also works great. However, when I run my extension using web-ext (npm run web-ext -- run) Firefox always sends a GET instead of a POST. This prevents me from using web-ext to develop my extension.

I have tried a bunch of different things and searched Google for answers but can not find anything related to FF converting an extension form POST to a GET. Here is a simplified version of my plugin code.

Background Script

var popupURL = chrome.extension.getURL('html/popup.html'),

  function handleClick() {
      currentWindow: true,
      active: true
    }, function (tabs) {
      if (tabs.length > 0) {
        activeTabId = tabs[0].id;
          url: popupURL,
          type: 'normal',
          height: 900,
          width: 680
        }, function (window) {
          popup = window;

// [snip]


Locally Package popup.html

<!DOCTYPE html>
    <meta charset="utf-8">
    <link rel="stylesheet" type="text/css" href="../css/popup.css"/>

    <div id="main">
      <form action="http://another.site.com/form-handler?page=page-N" method="post" name="pageDataForm" id="pageDataForm">
        <input type="hidden" name="pageData" value="blahblahblah" />
        <input type="submit" name="submit" value="submit"/>


When I click on the “Submit” button in the FF launched using web-ext and use the network browser, I see my form request sent using GET and not POST. But only in the browser launched using web-ext. I thought maybe it might have something to do with the CSP that the default profile is using or some other security restriction in the profile?

Additional Note:

I noticed if I create a brand new profile using ProfileManager, install my signed XPI production version of the plugin, the issue happens there as well - form POST sent as GET instead (with the POST body totally missing for obvious reasons).

Any help would really be appreciated.


(Niklas Gollenstede) #2

Did you add "http://another.site.com/*" to the permissions? (Btw. I doubt a non-TLS site will pass the review)

And you could try tho use a XHR to post your form, not that it should be necessary, but maybe it works.

(Dewittski) #3

Hi @NilkasG and thanks for your response.

The actual URL to post to comes from an option set with a custom options page as part of the Web Extension options. It is set by the user of the plugin and is unique to that user so there is no way I could add it to permissions ahead of time. (Also, yes, the URL is typically https.) What I included in the example above was a simplification.

Since a form post like this (not using AJAX) is not subject to cross domain restrictions, I really should not need to add it to any permissions, no? Also, it is currently working great for my users and they did not do anything special to their browser settings, just installed the XPI.


(Niklas Gollenstede) #4

Since a form post like this (not using AJAX) is not subject to cross domain restrictions

Interesting, I wasn’t aware of that:

I really should not need to add it to any permissions

It’s surprising how many things that should work don’t ^^

Adding "*://*/*" for a test once can’t hurt.

(Dewittski) #5

I wasn’t aware of it either until I read that very article you just referenced earlier today. :slight_smile:

No, no it can’t. I will give that a go.

(Dewittski) #6


I added it to my plugin’s permissions array and restarted FF using a new profile. Same results. :frowning:

  "permissions": [

Still seeing a GET in network browser.

(Niklas Gollenstede) #7

Still seeing a GET in network browser.

You mean the network tab of Firefox’s devtools, right?
Its not likely, but I have had those things report wrong stuff too. Are you sure the actual http method is get (wireshark, server logs, …)?

And two more ideas you’ve probably already read:

(Dewittski) #8

Thanks @NilkasG I will double-check I closed the tag and try the “formmethod” attribute to see if it helps. I will confirm in server logs that it is indeed POST also.

Given that it works to the same server for me if I use my “daily” FF profile and if I switch to my dev profile then does not work, I really feel like it is some sort of profile setting - possibly security related?

(Niklas Gollenstede) #9

It looks that way. I don’t have any more ideas that are more than guessing …

(Dewittski) #10

@NilkasG thanks for your time, much appreciated. I did confirm via nginx logs that nginx is receiving a GET and not a POST. :frowning: I also made sure the form tag was closed (it was) and added that “formmethod” attribute and no dice.

Anyone else have any ideas what in the FF profile could be causing FF to send a GET instead of POST?


(Dewittski) #11

I have created a very simple test plugin here. 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 within the temporary profile launched using web-ext it always seems to send a GET instead.

I did some further digging into the form-action directive of CSP and if this were what was causing it, the prescribed behavior according to the W3C CSP 2 spec is to act like a fatal network error occurred. Since the browser instead seems to arbitrarily decide to switch the POST to GET, it doesn’t seem CSP related, at least not the form-action.

(Niklas Gollenstede) #12

I just tried it in 4 profiles:

2015-11-07 - works - old main profile
2015-12-05 - nope - secondary profile
2016-09-24 - works - scarcely used debug profile
2017-02-13 - nope - my current main profile

So yes, id does depend on the profile somehow, but it is not strictly creation time related.
If you think that does you any good, I can mail you the profile from 2016-09-24.

Just to give you an idea what you might be facing, here is a weird profile related bug I had:

(Dewittski) #13

@NilkasG Thanks so much for giving the test a try. Any ideas how I might be able to track down what in the profile might be causing it? The profile is a big place :slight_smile:. Any pointers to things that may be related, etc?

(Niklas Gollenstede) #14

Obviously these are only suggestions:

  • make a backup and zip it, just to be sure you don’t accidentally delete the wrong files.
  • use web-ext run -p {{path}} to test with that profile
  • first, delete everything except for the prefs.js
    • if the problem persist, use bisection to find the (hopefully single) pref entry that causing it, by simply starting with en empty profile with ever fewer entries in the prefs.js
    • otherwise, do pretty much the same with the files/folders in the profile
  • operate on a fresh copy with each step, that way you always start from a known point

(Niklas Gollenstede) #15

Hm, I just noticed that I had e10s disabled in the “old main profile”. Now that I enabled it, your POST doesn’t work anymore!

The only pref I changed was browser.tabs.remote.autostart from false to true, which changed "Multiprocess Windows " on about:support from (Disabled) to (Enabled by user).

(Dewittski) #16

@NilkasG I didn’t even know what e10s was until just now. :slight_smile: OK, so my plugin is not compatible with “Electrolysis”. I wonder why though. What would running the plugin in a separate process have to do with it “automagically” changing my form posts into gets? I could totally understand IF it was a security thing AND it just STOPPED the form post altogether, but arbitrarily changing the meaning of an operation seems like a poor design choice. I wonder if I should open up an issue against mozilla e10s folks?

Also… THANK YOU for your continued, persistent, quality help.

(Niklas Gollenstede) #17

a poor design choice

That is defenetly not by design :D
All WebExtension and normal web APIs should be completely unaffected by e10s, so yes, it is probably worth a bug report.

(Dewittski) #18

@NilkasG thank you so much. I will file a bug and then reference it here for those that are interested that want to follow.

Thanks again!

(Noitidart) #19

Wow this topic was an awesome read! Learned a lot! (especially form post’ing is not restricted to same domain!)

(Dewittski) #20

@NilkasG @noitidart created bug 1347022 on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1347022. Let’s see what comes of it!