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

Status: VERIFIED FIXED

(Socorro :: Webapp, task)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot

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

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

Comment 1

[Peter Bengtsson [:peterbe]]

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.

Comment 2

[Peter Bengtsson [:peterbe]]

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.

Comment 3

[Schalk Neethling [:espressive]]

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.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

(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.

Comment 5

[Schalk Neethling [:espressive]]

Which is test is it that is failing for this or is it part of manual testing?

Comment 6

[Schalk Neethling [:espressive]]

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.

Comment 7

[Schalk Neethling [:espressive]]

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?

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Comment 9

[Schalk Neethling [:espressive]]

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

[[github robot]]

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

Comment 11

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 12

[Stephen Donner [:stephend] Not actively reading bugmail]

Thanks, all!

Verified FIXED on http://crash-stats-new-dev.allizom.org/fdjskl