Add postMessage support for report site issue data (other than screenshots) to bugform.js

[miketaylr]

This issue tracks the work necessary for mozilla/webcompat-team-okrs#107

Context:

In Firefox and Firefox for Android, when the user clicks "Report Site Issue", a few things happen:

1. some metadata about the page is collected (screenshot, console logs, value of some prefs, detect some libs, etc)
2. the metadata is POSTed to webcompat.com/issues/new in a new tab
3. the screenshot blob is sent to the webcompat form via postMessage

https://searchfox.org/mozilla-central/source/browser/extensions/report-site-issue/background.js#23 is where to start tracing the code.

We would like to port Report Site Issue to Fenix (like, beyond the simple link it is today, see mozilla/webcompat-team-okrs#110), but currently it does not support Experimental Web Extension APIs, which is how loadURIWithPostData is implemented. And there are no web extension APIs to open a tab and POST, rather than GET.

One way around this issue is to optionally send all the data via postMessage, along with the screenshot. We don't want to remove the POST abilities -- as it allows for HTTP client possibilities, but we should make sure we don't end up sending the data twice. Not 100% sure what that will look like right now, but I'm sure someone smart will think of something. 😄

[ksy36]

I've tried sending the data through postMessage from the addon and prefilling the form on the front end (url, details and reported_with fields). It works fine, the only thing is missing is extra_labels.

extra_labels param is being saved to session in the prefill step here and then they're being retrieved from session when the form is submitted . I think we could perhaps create a hidden field similar to details and prefill it on the front end as well.

@karlcow or @miketaylr is there any reason why it is saved to the session? Hopefully I'm not missing anything here :)

[miketaylr]

(edit: wow, this comment sat open for 4 hours... thought I hit submit, sorry :(((()

Let's do a bit of digging...

most recent commit, some refactoring: karlcow@10dba44

before that: #2006...

a3aed65#diff-a50603a824fb762e9303ee20ff0f2945R176-R212

We put the stuff from GET params in the session cookie so we wouldn't lose it if we redirected to GitHub to login before we had a form object.

In general, I think it's fine to put it in a hidden input, there's no reason for it to be treated differently than details. We don't want to remove support for the label param though -- there are a few clients using that (Fenix, currently, FirefoxReality browser... possibly the web extension addons?). So we should test that it still works for that use case.

[miketaylr]

Nice work on this one, @ksy36!