Closed Bug 1033289 Opened 8 years ago Closed 8 years ago

[ADU By Sig] Add Date Range Selectors


(Socorro :: Webapp, task, P3)


(Not tracked)



(Reporter: espressive, Assigned: espressive)


(Whiteboard: [QA+])

Based on user feedback in it is clear that the users need to be able to select their own date range for the graph.

Loading the graph initially using the selected number of days for the overall page should still happen however.
Thinking about these date selectors, and the channel selector that is made available if no version was passed to report/list

Would it not make sense to always have these selectors available?

That way, whether there was data or not, you can change the date range and/or the channel and reload the graph without having to navigate around or reload the entire page.
Flags: needinfo?(kairo)
Flags: needinfo?(benjamin)
That would be fine.
Flags: needinfo?(benjamin)
Target Milestone: 90 → 91
(In reply to Schalk Neethling [:espressive] from comment #1)
> Would it not make sense to always have these selectors available?

Yes, probably makes sense.
Flags: needinfo?(kairo)
While testing the work on this bug I ran into a scenario where there is only one result returned for the query:

"hits": [
"build_date": "2014-06-29", 
"os_name": "Windows", 
"buildid": "20140629004001", 
"adu_count": 2185, 
"crash_count": 1919, 
"adu_date": "2014-07-05", 
"signature": "nsTArray_base<nsTArrayFallibleAllocator, nsTArray_CopyWithConstructors<JS::Heap<JSObject*> > >::IncrementLength(unsigned int) | mozilla::net::HttpBaseChannel::ApplyContentConversions()", 
"product_name": "Firefox", 
"channel": "aurora"
"total": 1

In the above case, the code here:

removes this single instance as the adu_count value is not greater that the cutoff (the cutoff value in fact being equal to the adu_count) and as such the following line fails:

because finalData[0] is undefined

Possible solutions

1) We can test whether finalData still contains any items after the filter on line #111 has run
2) We only execute the filter if there are more than one item in finalData (the object build up by d3.nest())
3) We can change the filter to - return if d.values.adu_count >= cutoff;

:bsmedberg thoughts?
Flags: needinfo?(benjamin)
Target Milestone: 91 → 93
#1 sounds like the simplest option.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> #1 sounds like the simplest option.

So, what would be an accurate message to the user in these cases? There was no error in loading the data and, there was some data returned, the data was just not sufficient? i.e.

'Insufficient data to draw graph.'
Flags: needinfo?(benjamin)
Yes, that's fine.
Flags: needinfo?(benjamin)
Target Milestone: 93 → 94
QA Tests

Open crash-stats home
Navigate to top crashers and select a signature
On report/list, click the graph tab.

There are two loaders (spinners) on this tab.
-- First will be a loader indicating the content is loading
-- Following this loader will be another indicating that the graph is being loaded

NOTE: Depending on network speed, these might go past very quick and might not even be observed.


If there is no data for the graph, the user should be presented with a message such as the following:

No data returned for signature EnterBaseline


The graph should be displayed to the right of the form field.

There should at all times be three form field visible to the user, channel select drop down, a start and end date input (currently these require manual input and no date picker is provided).

Date Validation

The date validation rules are as follows:

1) Dates cannot be in the future
2) The start date cannot be after the end date.

NOTE: Also test this tab by clicking on a signature on the search results page.
Commits pushed to master at
Fix Bug 1033289, add date fields, make channel selector permanent
Merge pull request #2195 from ossreleasefeed/bug1033289-adubysig-add-date-selectors

Fix Bug 1033289, add date fields, make channel selector permanent
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: 94 → 95
You need to log in before you can comment on or make changes to this bug.