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.
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.
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.
Thanks,
Scott
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.
I wasn’t aware of it either until I read that very article you just referenced earlier today.
No, no it can’t. I will give that a go.
I added it to my plugin’s permissions array and restarted FF using a new profile. Same results.
"permissions": [
"activeTab",
"storage",
"*://*/*"
],
Still seeing a GET in network browser.
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:
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?
It looks that way. I don’t have any more ideas that are more than guessing …
@NilkasG thanks for your time, much appreciated. I did confirm via nginx logs that nginx is receiving a GET and not a POST. 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?
Thanks,
Scott
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
.
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:
https://discourse.mozilla-community.org/t/convert-from-sqlite-to-indexeddb/13315/8?u=nilkasg
@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 . Any pointers to things that may be related, etc?
Obviously these are only suggestions:
web-ext run -p {{path}}
to test with that profileprefs.js
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).
@NilkasG I didn’t even know what e10s was until just now. 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.
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.
@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!
Wow this topic was an awesome read! Learned a lot! (especially form post’ing is not restricted to same domain!)
@NilkasG @noitidart created bug 1347022 on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1347022. Let’s see what comes of it!
One could hardly wish for a better bug report ^^
(Other than no bug report because there was no bug in the first place of course …)