[socorro-crashstats] 404 page doesn't have working products or versions

VERIFIED FIXED

Status

VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: stephend, Assigned: espressive)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 671643 [details]
Screenshot

The 404 page is missing products and versions in its selectors:

http://crash-stats-new-dev.allizom.org/fdjskl
(Reporter)

Updated

6 years ago
Assignee: nobody → sneethling
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.
(Assignee)

Comment 3

6 years ago
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.
(Reporter)

Comment 4

6 years ago
(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.
(Assignee)

Comment 5

6 years ago
Which is test is it that is failing for this or is it part of manual testing?
(Assignee)

Comment 6

6 years ago
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.
(Assignee)

Comment 7

6 years ago
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?
Flags: needinfo?
(Reporter)

Comment 8

6 years ago
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.
Flags: needinfo?
(Assignee)

Comment 9

6 years ago
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.

Comment 10

6 years ago
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

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

6 years ago
Created attachment 673051 [details]
Post-fix screenshot
(Reporter)

Comment 12

6 years ago
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.