[webcompat reporter] extra_labels are not sent to webcompat.com
Categories
(Web Compatibility :: Tooling & Investigations, defect, P1)
Tracking
(Not tracked)
People
(Reporter: karlcow, Unassigned)
References
Details
As identified in https://github.com/webcompat/webcompat.com/issues/2869
it seems we are not sending the extra_labels keyword inside the JSON.
This should be fixed. I'm not sure if it was regressed by Bug 1535479 or if it happened before when we implemented the JSON payload for submitting the issue to the form.
Let's figure out.
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 1•5 years ago
|
||
so it seems to be in the initial version of the webextension version.
https://searchfox.org/mozilla-central/rev/c5d0750aa4f438be2fc3b552a81a7f841c504d2a/mobile/android/extensions/report-site-issue/background.js#165
And the previous system on Fennec didn't have labels.
https://hg.mozilla.org/try/diff/0da2006f9d938772df39d1db011a4c4a21c1d103/mobile/android/chrome/content/WebcompatReporter.js#l1.126
and before on Desktop
https://searchfox.org/mozilla-central/diff/b572526d9c7fff214bcdc92e81e59beddc981389/browser/extensions/webcompat-reporter/content/WebCompatReporter.jsm
There was a label.
So maybe I screwed up on the server side.
|
|
Reporter | |
Comment 2•5 years ago
|
||
ok found in https://github.com/webcompat/webcompat.com/issues/2869#issuecomment-492472245
This has to be fixed on the reporter side.
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 3•5 years ago
|
||
In https://bugzilla.mozilla.org/show_bug.cgi?id=1544359#c3 Ksenia noticed that this is not working yet.
Ksenia, could you copy paste an example of the full HTTP request payload sent to the server.
So we can test on both sides and detect if we missed something.
Thanks. :)
|
|
||
Comment 4•5 years ago
|
||
Re-posting my comment (wrong bug!)
I just filed https://github.com/webcompat/webcompat-tests/issues/1839 to test if the staging.webcompat.com/issues/new?label=browser-fenix worked, and it does seem like something is busted here.
<!-- @browser: Firefox 68.0 -->
<!-- @ua_header: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0 -->
<!-- @reported_with: -->
There should be <!-- @extra_labels: browser-fenix -->, and reported_with should default to web.
A few notes I took on how this should work,
When the browser opens /issues/new, it will end up in the prefill condition,
Inside prepare_form extra_labels are pulled from a label GET param, if it exists.
However, if there is a POST with json data, that will win, and a form_data[‘extra_labels’] key will exist.
(So the expected key for the incoming data should be extra_labels, I think.)
That gets saved to the session cookie:
And then added back to the form object when we’re in the create condition:
We then end up in report_issue:
Which will call build_formdata
If extra_labels exists there, we add it to the metadata_keys dict:
In theory, we should then come up with a list of the extra_labels from get_metadata, and hide those in the issue body:
Then there’s a web hook after the issue is open:
https://github.com/webcompat/webcompat.com/blob/78596f47aee2df83217be949e94928d70273bef1/webcompat/webhooks/helpers.py#L182
It pulls the labels from the issue body:
(And follow the call stack down to related metadata)
Right now labels won't get added locally or on staging, because we have a webhook that sets the label. I'm not sure why the staging webhook isn't working, I think it used to?
All the hooks are failing for some reason, https://github.com/webcompat/webcompat-tests/settings/hooks/10039471
|
||
Comment 5•5 years ago
|
||
So this is what being sent when I click on the Report site issue button when testing locally:
{
"url": "https://www.shaw.ca/store/",
"utm_source": "desktop-reporter",
"utm_campaign": "report-site-issue-button",
"src": "desktop-reporter",
"details": {
"gfx.webrender.all": false,
"gfx.webrender.blob-images": true,
"gfx.webrender.enabled": false,
"image.mem.shared": true,
"buildID": "20190515140852",
"channel": "default",
"consoleLog": [],
"hasTouchScreen": false,
"mixed active content blocked": false,
"mixed passive content blocked": false,
"tracking content blocked": "false",
"hasMobify": true
},
"extra_labels": [
"type-mobify"
]
}
This test issue has @extra_labels in it, so I assume that is how it should be? If yes then it's working correctly.
No labels got created though, so that what confused me in that comment
|
|
Reporter | |
Comment 6•5 years ago
|
||
This test issue has @extra_labels in it, so I assume that is how it should be? If yes then it's working correctly.
cool thanks a lot. That will speed up the debugging.
No labels got created though, so that what confused me in that comment
There are two phases:
- Create a body which contains
<!-- @extra_labels: browser-fenix -->as mentioned by mike. - Create the label once this body has been made.
The step 1. is not happening so there is indeed a bug on webcompat.com side too. :)
I'll investigate today.
|
|
Reporter | |
Comment 7•5 years ago
|
||
so I fixed staging. The labeler is working again. Now we can try to tackle the issue with the webcompat reporter.
|
|
Reporter | |
Comment 8•5 years ago
|
||
reminder
For testing staging with webcompat-reporter
extensions.webcompat-reporter.newIssueEndpoint in about:config and changing it to https://staging.webcompat.com/issues/new
|
|
||
Comment 9•5 years ago
|
||
Thanks Karl, tested with webcompat reporter, working as expected :)
|
|
||
Comment 10•5 years ago
|
||
This was fixed as a part of the patch for the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1544359
Description
•