Created attachment 671643 [details] Screenshot The 404 page is missing products and versions in its selectors: http://crash-stats-new-dev.allizom.org/fdjskl
What would it take to change the tests so that they don't *depend* on there being a dropdown of products and versions? My current trainofthought is that we shouldn't have any navigation in the 404 page.
The old PHP code had the products hardcoded: https://github.com/ossreleasefeed/socorro/blob/master/webapp-php/application/views/kohana_error_page.php#L47 And there is no versions drop down on prod 404 pages.
Currently the products on the 404 and 500 page is hard coded and there are no versions so, I am wondering if we should not remove the check for products/versions from the QA tests for these pages.
(In reply to Schalk Neethling [:espressive] from comment #3) > Currently the products on the 404 and 500 page is hard coded and there are > no versions so, I am wondering if we should not remove the check for > products/versions from the QA tests for these pages. We were, originally, going for test-for-test parity with Web QA's tests (but I agree that's not an ultimate/final metric). I and Matt are up for a healthy discussion of long-term and short-term coverage for the Django-app, and this is part of that.
Which is test is it that is failing for this or is it part of manual testing?
Also, seeing that reports selection will not yield anything useful without at least a product being selected, I reckon we should create a separate base template for the 404, 500 and any other 'error' pages to extends that does not include any of those drop down fields. The above assumes there is no simple way in Jinja to determine that the template is being rendered because of a error and thus we can make those fields conditional.
Thinking about it, actually we could just wrap those field is an if condition and if products is None, just do not render them. Thoughts?
No automation for testing functionality on the 404 page; just a manual test, and I was comparing to prod, is all. I thought in the meeting we discussed and perhaps decided that we could just rid ourselves of the models/views on this page.
Hey Stephen, Yeah, I was not sure about what I actually need to do, thought there was an automated test. I reckon I am just gonna remove all of those fields from the error pages if nobody objects to it.
Commits pushed to master at https://github.com/mozilla/socorro-crashstats https://github.com/mozilla/socorro-crashstats/commit/b07345712c105ff79fc7fff9f3682c98aa47955b dont show select drop downs on error pages fixes bug 801924 https://github.com/mozilla/socorro-crashstats/commit/15c4c959831935149f7bdf96e44e25f460d23c87 Merge pull request #178 from ossreleasefeed/do-not-render-dropdowns-on-error-pages-801924 dont show select drop downs on error pages fixes bug 801924
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Thanks, all! Verified FIXED on http://crash-stats-new-dev.allizom.org/fdjskl
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.