Closed Bug 550538 Opened 15 years ago Closed 13 years ago

Provide easily-accessible list of URLs-for-signature to logged-in users

Categories

(Socorro :: Webapp, task)

Product:
Socorro
Component:
Webapp
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: alqahira, Assigned: espressive)

References

Details

(Whiteboard: [Q42011wanted] [Q12012wanted])

Attachments

(1 file)

qa - verified
164.09 KB, image/png
Details
I thought I had already seen a bug on this, but I can't find anything related with "URL" in the summary…. For certain types of crashes, it would be really useful to have a view that pulls all the submitted URLs for that signature out, instead of having to open each report individually and hope that there's a URL there. I have a couple of rough thoughts about how this might work: 1) Add a new "tab" to the top of the "Crash Reports for SignatureFOO" page and to the top of individual reports for SignatureFOO (e.g., like Bugzilla and Comments on the former, and Comments and Correlations on the latter). The advantage of this method is that you get "just" the URLs. The main disadvantage I see here is that lots of times the comment contains specific steps you need to perform to trigger the crash, and you'd have to find and open the individual report to see the STR for that URL from the comment. 2) Include URLs in the Comments tab, too. The advantage of this is that it keeps the number of tabs down and that you can read the comment/STR right with the URL (and, since email addresses already appear on the Comments view when logged-in, there's probably code that can be reused). There are two big disadvantages of combining things, I think. One is cosmetic, in that the current Comments "tab" layout looks busy, with too many things in blue "front-and-center" competing for attention. That's probably pretty easy to solve. The other disadvantage is that I'm sure that page is built off of results in the "Comments" field, whereas I'd want URLs included even when there aren't associated comments, and making an "either-or when logged in, comments only when logged out" query to construct that view seems like it could be painful. 3) There's a third option that I'm less fond of for layout reasons, but which may be the easiest to implement, actually: when logged in, add an 11th column to the "Crash Reports for SignatureFOO" page (e.g. https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsDocShell%3A%3AFirePageHideNotification(int)&version=Camino%3A2.0.2) next to the Comment column, that includes the URL. I could then sort on that column, see the URLs, and see any comments that might be associated. There are disadvantages to having that everywhere (e.g. non-browser apps) and the fact that URLs tend to be long strings that don't have great wrapping options, but it may work.
Severity: normal → enhancement
another option is to get something like bug 630293 that we have for firefox, and bug 630293 that will be coming for fennec, we could also just change the format of the reports so they include the product name
(In reply to comment #1) > another option is to get something like bug 630293 that we have for firefox, > and bug 630293 that will be coming for fennec, we could also just change the > format of the reports so they include the product name Are those (would those be) available somewhere that the set of people who can currently see URLs on Socorro can access them? Since I don't know what those reports look like, I can't comment on how useful they'd be to the use-cases I've encountered that led me to file this bug, but if they would address my needs, they'd certainly be a faster path than adding UI to crash-stats. :)
Option 1) in comment #0 is what we should implement. The contents of this tab should be something like in bug 671955 comment #3 or bug 678018 comment #1 or bug 675260 comment #4 - just in a nice table and without stripping potentially-privacy-related stuff, which we still will need to do manually upon copying this into bug comments (but that's the whole reason why it needs to be behind a password and only accessible to a small, trusted group of people.
Oh, and I think that this is nowadays something we can create on-demand in that page dynamically from live data, with the filters the specific reports/list has, right?
Is it too out of scope to also have the reverse as well? i.e. given a url, what signatures, branches, os' etc occur at that url?
(In reply to Bob Clary [:bc:] from comment #5) > Is it too out of scope to also have the reverse as well? i.e. given a url, > what signatures, branches, os' etc occur at that url? For this bug, yes, it's too out of scope. But it's an interesting idea, even if we already have "Topcrashers by URL" right now that are very similar and a report that nobody really looks at today. Still, if a report like you describe is of interest to you, it should go into its own bug.
FYI, bc filed bug 694071 based on discussion in comments 5 and 6. Any ideas or thoughts about that proposal should be directed there.
Whiteboard: Q42011wanted
Over to Schalk for UI work.
Assignee: nobody → sneethling
Whiteboard: Q42011wanted → [Q42011wanted] [Q12012wanted]
Target Milestone: --- → 2.4.2
Component: Socorro → General
Product: Webtools → Socorro
In order to create a UI where having the comments and URLs on the same tab or row/column there needs to exist an association between comments and these URLs. Currently I believe the association is between the comment and the crash signature and the association between the comment and any URLs does not exist. With this, adding the URLs to the 'Comments' tab will not assist in easily seeing the steps to reproduce that might be in the comment because the associated URL will not be grouped together but, it will be more like a list of URLs and a list of comments in the same tab, but no association. The same goes for adding an additional column, there are other reason why suggestion 3 is also not recommended, to the top crasher page. This basically only leaves option 1 open. This means an additional tab on the report/list page that is filled with all URLs related to the crash signature. Would this add value to Socorro? If there does exist an association, or one can be created, between a comment and URL, then option 2 would be the way to go as one can have the SRP as well as the URL all in one place. Thoughts?
Nah, comments tab is wrong for this anyhow. This either should be a new tab that is visible only when logged in, or as another table in the signature summary - though I think the former is the better way to do this.
BTW, see e.g. bug 702999 comment #3 for how such a list of URLs should look (formatted more nicely, of course).
As discussed on IRC, this will then be a list of URLs as well as the number of times they have been reported for a crash sig ordered by the most reported to the least. All of this will be in a new tab called, URLs on the report/list page
Schalk, exactly that sounds good to me!
Schalk: so will this be like a new signature summary report? Also, note that we now have in the database a fairly sanitized column of domains only. Not sure that's relevant to this, but worth thinking about.
[:jberkus] As touched on, on IRC this is going to be new tab on the report/list page that lists the URL that has been reported for the current signature. In terms of the domains only, for this one I need the full urls which is going to be pulled from the reports table.
Status: NEW → ASSIGNED
Schalk, You shouldn't be using "reports" for this. In fact, you shouldn't be using "reports" for *any* new feature, period. For getting the full URL, you should use reports_clean + reports_user_info.
[:jberkus] Ah I should mention this to [:rhelmer]
UI is priority for release 2.4.2
Target Milestone: 2.4.2 → 2.4.3
Target Milestone: 2.4.3 → 2.4.4
Target Milestone: 2.4.4 → 2.5
Schalk, From a database perspective, 2.5 will be ESR *only*. So I think you want to bump this to 2.5.1. Who will be working on the database access for this feature? I should work with them, this could make a good matview training opportunity.
Josh [:jberkus] Bumping it to 2.5.1, thanks for the heads up. In terms of the DB access, I really want to handle this one from DB to UI myself so, it will be me working on this.
Target Milestone: 2.5 → 2.5.1
Target Milestone: 2.5.1 → 2.5.2
Target Milestone: 2.5.2 → 2.5.3
Schalk, Let's make an appointment to work on those two features. I think you can easily get what you want from existing tables, but I'm not 100% clear on what data is wanted.
the two pieces of data that are most useful here are a ranked order of domains and URLs that can be used to try and reproduce the bug. comments that are apart of these lists can also be helpful to understand what the user might have been doing when the browser recorded the url just before crahsh. I've been generating these lists by looking at the last one day or last 100 or so crash reports with the same signature, then sorting and counting that list so we can see the most popular sites and urls that might be connected with the crash, and how the distributon of domains and URLs look. From the list we can see things like. If all the crashes come from one or two urls or sites we are likely to have a reproducible test case at that url.... The urls might be slightly different, but are concentrated to just a few sites, indicating that its a particular interaction with the site, rather than the exact same content or url that might be causing the crash. or, it might be just general browsing patterns in the domain and urls list showing the crash is probably associated with garbage collection or some other event unconnected directly to the last page visited. The url list can also help us to confirm start up crashes, and how far the browser made it to the start sequence if the session:restore or start page shows up high in the url list. we can also see geographic patterns in the crash if many of the crashes come from differnent regions such as .ru, .br... and particular ads or content might be served across many sites.
What are we looking the crashes up by? Product/version? Signature? What? There are 3 columns in reports_clean and reports_user_info you'll want: reports_clean.domain reports_user_info.url reports_user_info.comments Note that it would be useful to also provide totals by domain as well as specific URL.
> What are we looking the crashes up by? Product/version? Signature? What? I've just been looking up by signature.
(In reply to [:jberkus] Josh Berkus from comment #24) > What are we looking the crashes up by? Product/version? Signature? What? This is going to be a tab in report/list, so bound by the same contraints like e.g. comments or reports tabs there: 1) Always by signature 2) Bound to product(s)/version(s) and date ranges Here's some examples of pages this should appear on (for people with a login) and the constraints they imply: https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-03-15&signature=DispatchHookW&version=Firefox%3A11.0 "Results within 7 days of now, and the version is one of Firefox:11.0 and the crashing process was of any type (including unofficial release channels)." https://crash-stats.mozilla.com/report/list?signature=DispatchHookW "Results within 1 weeks of now and the crashing process was of any type (including unofficial release channels)." https://crash-stats.mozilla.com/report/list?product=Firefox&product=SeaMonkey&version=Firefox%3A11.0&version=Firefox%3A10.0.3esr&version=Firefox%3A10.0.2&version=SeaMonkey%3A2.8&version=SeaMonkey%3A2.7.2&query_search=signature&query_type=contains&query=DispatchHookW&reason_type=contains&date=03%2F15%2F2012%2012%3A39%3A21&range_value=2&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=DispatchHookW "Results within 2 weeks of 03/15/2012 12:39:21, where the crash signature contains 'DispatchHookW', and the product is one of Firefox, SeaMonkey, and the version is one of Firefox:11.0, Firefox:10.0.3esr, Firefox:10.0.2, SeaMonkey:2.8, SeaMonkey:2.7.2 and the crashing process was of any type (including unofficial release channels)." https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A11.0&query_search=signature&query_type=contains&reason_type=contains&date=03%2F15%2F2012%2012%3A43%3A23&range_value=1&range_unit=days&hang_type=crash&process_type=browser&do_query=1&signature=DispatchHookW "Results within 1 days of 03/15/2012 12:43:23, and the product is one of Firefox, and the version is one of Firefox:11.0 and the crashing process was a browser." In all those cases we want the list of URLs with frequency counts, as described in comment #13, for reports with that signature and the constraints given as parameters to that page and described above.
Kairo: Hmm. If you want this to be combine with search, rather than with Signature Summary, it becomes a much more complicated feature and will need to wait for Elastic Search. Are you sure this is what you want?
Schalk, Assuming that contrary to what Kairo says above we're doing this as part of Signature Summary and NOT as part of search, then you can do this: -- group by domains SELECT domain, count(*) as crash_count FROM reports_clean WHERE date_processed BETWEEN '2012-03-01' and '2012-03-04' AND product_version_id = ANY ( get_product_version_ids ( 'Firefox','10.0.2','12.0a1' ) ) GROUP BY domain; -- group by urls SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) WHERE reports_clean.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND reports_user_info.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND product_version_id = ANY ( get_product_version_ids ( 'Firefox','10.0.2','12.0a1' ) ) GROUP BY url; -- get urls and comments SELECT uuid, url, comment as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) WHERE reports_clean.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND reports_user_info.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND product_version_id = ANY ( get_product_version_ids ( 'Firefox','10.0.2','12.0a1' ) ) ORDER BY date_processed DESC; The last query might be better used as an alternative to the comments tab. Note that the get_product_version_ids function is new, and not yet available on all copies of the PG database.
(In reply to [:jberkus] Josh Berkus from comment #27) > Hmm. If you want this to be combine with search, rather than with Signature > Summary, it becomes a much more complicated feature and will need to wait > for Elastic Search. Erm, reports/list is not search, is it? Also, if Signature summary does not follow the criteria of the pages themselves, the way I posted it in comment #26, that's a bug anyhow.
Target Milestone: 3 → 4
Target Milestone: 4 → 5
Target Milestone: 5 → 6
Robert, Singature Summary filters on ONLY signature, product, and version(s). Attempting to make it filter on any arbitrary combination of possible search criteria would both make the feature far more complicated, and way slower.
(In reply to [:jberkus] Josh Berkus from comment #30) > Singature Summary filters on ONLY signature, product, and version(s). Yes, that might be a bug to some degree, but let's leave that out here for now. I think we can go for the same criteria as Signature Summary for now. We might need/want to extend that for other parameters that report/list can take, but let's not over-engineer for that right now and rather get something up that works for the "normal" cases.
Target Milestone: 6 → 7
Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=550538#c28 I wonder when we will need the three different queries. Seems to me, from what we need for the UI, that either the 'group by domain' or 'group by urls' will be sufficient or has something changed in terms of the UI?
I *think* that the one he listed as "group by URLs" is what we really want - though the domain one might be an additional nice-to-have.
Depends on: 745866
we needed the group by domain to first spot the high volume sites, then the group by url to find the places within those sites that are particularly crashy. for a given site we might have single pages where we we can find reproducible crashes and they will show up easily in the url report. the harder ones to find are particular user patterns like a login sequence or form submission where the activity and content is similiar for every user, but the url might be different and include session info. any tools that help us to spot the similar patters quickly are really helpful. that's what we use comments and parts of the full url to help diagnose.
Up until now we never had the "domain" list, not even when we retrieve stuff manually with out scripts, so we can do that in a followup if wanted. And we already have the comments anyway in report/list so no need to care about them in this bug. The list of full URLs is what this bug is meant for, everything else can go into a followup, let's not have scope creep here or we are delaying an important feature with it. It looks pretty much like we won't get (m)any other important features done in the next weeks to months due to release management changing stuff around again, so let's get at least this one finished.
This is urls for a specific signature but, none of the SQL queries takes a signature as a parameter, am I missing something?
yes, signature is required. I really would call the domain list scopre creep. We have been doing it for a while and its really a very simple operation to strip off the directory part, sort and count the list of instances for unique domains. Here is an example of the kinds of sanitized lists that Marcia and I have been putting in bugs for the last many years. https://bugzilla.mozilla.org/show_bug.cgi?id=633473#c4 Thats what we are trying to do here.
Schalk, Simple: SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) WHERE reports_clean.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND reports_user_info.date_processed BETWEEN '2012-03-01' and '2012-03-04' AND product_version_id = ANY ( get_product_version_ids ( 'Firefox','10.0.2','12.0a1' ) ) AND signature_id = 32431112 GROUP BY url;
So, full exapaned version given everything we've discussed: SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) JOIN signatures USING ( signature_id ) WHERE reports_clean.date_processed BETWEEN '$start_date' and '$end_date' AND reports_user_info.date_processed BETWEEN '$start_date' and '$end_date' AND product_version_id = ANY ( get_product_version_ids ( '$product1','$version1','$version2' ) || get_product_version_ids ( '$product2','$version3','$version4' ) ) AND signature = '$signature' GROUP BY url; Note that the "|| get_product_version_ids" is optional. Its for when the user has specified more than one product they want to search for.
Target Milestone: 7 → 8
Pull request sent for the service(https://bugzilla.mozilla.org/show_bug.cgi?id=745866), as soon as that is ok'd, I will complete the rest of the work.
Target Milestone: 8 → 9
Assignee: sneethling → nobody
Component: General → Webapp
QA Contact: socorro → webapp
Target Milestone: 9 → 10
Assignee: nobody → sneethling
Current query for products and versions SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) JOIN signatures USING ( signature_id ) JOIN product_versions USING ( product_version_id ) WHERE reports_clean.date_processed BETWEEN %(start_date)s AND %(end_date)s AND reports_user_info.date_processed BETWEEN %(start_date)s AND %(end_date)s AND signature = %(signature)s AND url <> '' AND (( product_name = %%(product%s)s AND version_string IN %%(version%s)s )) GROUP BY url ORDER BY crash_count DESC LIMIT 100
"All" products, which actually picks up only "current" products: SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) JOIN signatures USING ( signature_id ) JOIN product_versions USING ( product_version_id ) WHERE reports_clean.date_processed BETWEEN %(start_date)s AND %(end_date)s AND reports_user_info.date_processed BETWEEN %(start_date)s AND %(end_date)s AND signature = %(signature)s AND url <> '' AND (( product_name = %%(product%s)s )) AND %(end_date)s BETWEEN product_versions.build_date AND product_versions.sunset_date GROUP BY url ORDER BY crash_count DESC LIMIT 100
[;jberkus] So would the following be: AND (( product_name = 'Firefox', 'Fennec' )) or AND (( product_name = %%(product%s)s ) OR ( product_name = %%(product%s)s ))
AND (( product_name IN ('Firefox', 'Fennec') ))
===================================== providing both products and versions ===================================== SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) JOIN signatures USING ( signature_id ) JOIN product_versions USING ( product_version_id ) WHERE reports_clean.date_processed BETWEEN '2012-03-24T11:29:07+00:00'::timestamptz AND '2012-03-31T11:29:07+00:00'::timestamptz AND reports_user_info.date_processed BETWEEN '2012-03-24T11:29:07+00:00'::timestamptz AND '2012-03-31T11:29:07+00:00'::timestamptz AND signature = E'nsScriptSecurityManager::CheckPropertyAccessImpl(unsigned int, nsAXPCNativeCallContext*, JSContext*, JSObject*, nsISupports*, nsIURI*, nsIClassInfo*, char const*, int, void**)' AND url <> '' AND ( product_name IN ('FennecAndroid', 'Firefox') ) AND '2012-03-31 11:29:07+00:00' BETWEEN product_versions.build_date AND product_versions.sunset_date GROUP BY url ORDER BY crash_count DESC LIMIT 100 ======================== Providing only products ======================== SELECT url, count(*) as crash_count FROM reports_clean JOIN reports_user_info USING ( UUID ) JOIN signatures USING ( signature_id ) JOIN product_versions USING ( product_version_id ) WHERE reports_clean.date_processed BETWEEN '2012-03-27T00:00:00+00:00'::timestamptz AND '2012-04-03T00:00:00+00:00'::timestamptz AND reports_user_info.date_processed BETWEEN '2012-03-27T00:00:00+00:00'::timestamptz AND '2012-04-03T00:00:00+00:00'::timestamptz AND signature = E'nsXHREventTarget::GetListenerAsJSObject(nsDOMEventListenerWrapper*)' AND url <> '' AND ( ( product_name = E'Firefox' AND version_string IN (E'14.0a1') ) ) GROUP BY url ORDER BY crash_count DESC LIMIT 100
Queries above are swapped around
Pull request sent :: https://github.com/mozilla/socorro/pull/580 TEST CASE --------- There are three test cases for this report: 1) From TCBS Load top crashers and select one of the signatures. On the resulting page (report/list) there should be a new tab listing URLs for the selected criteria. 2) From search with versions Load up the search page and select one or more products as well as one or more versions for each product. NOTE: selecting all will overwrite all versions selected. This is not something introduced with this new feature but current behavior. Select one of the resulting signatures and on the resulting page (report/list) there should again be a new tab entitled URLs listing urls for the selected criteria. 3) From search all versions Load up the search page again. This time select one or multiple products and select the 'ALL' versions option. Select one of the resulting signatures an on the resulting page (report/list) you should once again see the new URLs tab with a list of URLs. For all of these the table will consist of clickable links as well as a total count for each entry. The result are limit to a max of 100 results.
Important note, the bug title suggests this but, you have to be logged in to see/test/use this feature
Commits pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/837ef0f72b623036273675c172f15de4091b029e making urls by sig available to logged in users fixes bug 550538 https://github.com/mozilla/socorro/commit/7877ebc27dc9e23e9e1229fb8e4283728e551b57 Merge pull request #580 from ossreleasefeed/url-by-sig-front-end-550538 making urls by sig available to logged in users fixes bug 550538
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Commits pushed to stage at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/837ef0f72b623036273675c172f15de4091b029e making urls by sig available to logged in users fixes bug 550538 https://github.com/mozilla/socorro/commit/7877ebc27dc9e23e9e1229fb8e4283728e551b57 Merge pull request #580 from ossreleasefeed/url-by-sig-front-end-550538
QA verified on stage - given the synopsis of the functionality that was implemented (comment 47) I believe espressive captured the intent of the feature enhancement. Kairo, your 2 cents worth would be helpful.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-moztrap?
OS: Mac OS X → All
Hardware: x86 → All
Attached image qa - verified —
Commit pushed to stage at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/064965d0d94f3d8db0b1ea411993bd002e16a834 making urls by sig available to logged in users fixes bug 550538
Status: VERIFIED → RESOLVED
Closed: 13 years ago → 13 years ago
Status: RESOLVED → VERIFIED
(In reply to Matt Brandt [:mbrandt] from comment #51) > Kairo, your 2 cents worth would be helpful. From what I'm seeing, it looks fine, yes. Eager to see it on prod! :)
kairo: Thanks for taking a look. There will be quite a few happy people when this feature lands on production.
is there a quick and easy way to make the url list sortable by clicking on the top of that column? that would make organization of the list by domains sort of easy to get at and provide some of what I asked for in comment 37.
(In reply to chris hofmann from comment #56) > is there a quick and easy way to make the url list sortable by clicking on > the top of that column? If it doesn't do that right now, please file a followup bug on it. The code as it is now is on the staging branch and unless something critical happens or something needs to backout, no other patches land there before being released tomorrow. The feature as implemented is already tremendously helpful, so we should let it get deployed. Any further improvements should have their own bugs and land as they are finished.
[:chofmann] I was unsure whether we wanted sorting on the URL cells as the URLs are currently sorted from most reported to least. I can see how this can be useful though so, I will open up a follow on bug and get this in there.
We had a bug sneak up on us with KaiRo's scripts. The code in this feature broke his scripts, as his scripts sometimes passes no version parameter and the new code expects a version parameter, even if it is empty. A last minute fix was pushed to rectify this problem: https://github.com/mozilla/socorro/pull/610
(In reply to Schalk Neethling [:espressive] from comment #60) > We had a bug sneak up on us with KaiRo's scripts. > > The code in this feature broke his scripts, as his scripts sometimes passes > no version parameter and the new code expects a version parameter, even if > it is empty. > > A last minute fix was pushed to rectify this problem: > https://github.com/mozilla/socorro/pull/610 This turned out not to be enough unfortunately, we need to support URLs of the form: https://crash-stats.mozilla.com/report/list?signature=CrashIfInvalidSlot But product is required for the new service, we need to do something similar to how we support "versions=ALL" for products. After discussing with nhirata and kairo in IRC, we're going to leave this as-is and issue a followup fix ASAP.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=CrashIfInvalidSlot works, so the versions missing case is covered correctly (and actually something that you can get when selecting "All" versions from advanced search), the only thing not working correctly on prod is product missing, which should go for all products.
(In reply to Robert Helmer [:rhelmer] from comment #61) > https://crash-stats.mozilla.com/report/list?signature=CrashIfInvalidSlot BTW mbrandt and I discussed adding this URL to the selenium test ^ Let's open a separate bug to discuss this, there may be more we support.
(In reply to Robert Helmer [:rhelmer] from comment #63) > (In reply to Robert Helmer [:rhelmer] from comment #61) > > https://crash-stats.mozilla.com/report/list?signature=CrashIfInvalidSlot > > BTW mbrandt and I discussed adding this URL to the selenium test ^ > > Let's open a separate bug to discuss this, there may be more we support. Bug 758055 filed to track the discussion on the automation needs.
Commits pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/abfd97fec77e48f83738dfe52fd748efbb3f8f9f handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538 https://github.com/mozilla/socorro/commit/bd4d9825e7b65932a580ff8b20aad49da262385c Merge pull request #614 from ossreleasefeed/allow-all-products-urls-for-sig handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Commit pushed to stage at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/2d5e1142590dcad4f0ece2f0275f8e65378c25eb handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538
Commits pushed to stage at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/cb6873804c193f5de44a963a3a19dbfb819bd2c7 handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538 https://github.com/mozilla/socorro/commit/54cb1a3d1e7ce07a26928c871f7150fb02413418 Merge pull request #616 from rhelmer/stage fixes bug 550538 (regression from Socorro 10)
Verified FIXED on staging: 1) https://crash-stats.allizom.org/report/list?product=Firefox&signature=CrashIfInvalidSlot returns results, as expected. 2) As does https://crash-stats.allizom.org/report/list?signature=CrashIfInvalidSlot (which also returns Thunderbird results) 3) This returns *no* results, as expected: https://crash-stats.allizom.org/report/list?product=Camino&signature=CrashIfInvalidSlot 4) Finally, https://crash-stats.allizom.org/report/list?signature=TouchBadMemory%20|%20mozalloc_abort%20|%20NS_DebugBreak_P%20|%20X11Error also returns the right results, as expected. Our Selenium tests for socorro.stage passed (also as expected, once data was finally loaded): http://qa-selenium.mv.mozilla.com:8080/view/Socorro/job/socorro.stage/627/
Status: RESOLVED → VERIFIED
[:stephend] Thanks a million for verifying, much appreciated.
As discussed with [:mbrandt] on IRC the reason things broke is because the new feature was expecting certain parameters that Kairo's scripts omitted, and was not part of any tests so, the changes to fix the regression was only to the new feature and therefore nothing other then the report/list page is being effected.
Commits pushed to stage at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/5107cc946311c9490179d290ab80f1d6fc31c8d1 making urls by sig available to logged in users fixes bug 550538 https://github.com/mozilla/socorro/commit/eb6d5fb5a509b80f37e18c9cfa7314c909aaa06f handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538
Status: VERIFIED → RESOLVED
Closed: 13 years ago → 13 years ago
Re-verified on stage - followed comment 70's brilliant steps to test 1) https://crash-stats.allizom.org/report/list?product=Firefox&signature=CrashIfInvalidSlot returns results, as expected. 2) As does https://crash-stats.allizom.org/report/list?signature=CrashIfInvalidSlot (which also returns Thunderbird results) Followed verification steps laid out in comment 3) This returns *no* results, as expected: https://crash-stats.allizom.org/report/list?product=Camino&signature=CrashIfInvalidSlot The urls tab is also still present and populated with the correct data 4) Finally, https://crash-stats.allizom.org/report/list?signature=TouchBadMemory%20|%20mozalloc_abort%20|%20NS_DebugBreak_P%20|%20X11Error also returns the right results, as expected. Our Selenium tests for socorro.stage passed (also as expected, once data was finally loaded):http://qa-selenium.mv.mozilla.com:8080/job/socorro.dev/5881/
Status: RESOLVED → VERIFIED
Commits pushed to admin-refactor at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/abfd97fec77e48f83738dfe52fd748efbb3f8f9f handling all possible URLs on reporl list when calling urls for signature service fixes bug 550538 https://github.com/mozilla/socorro/commit/bd4d9825e7b65932a580ff8b20aad49da262385c Merge pull request #614 from ossreleasefeed/allow-all-products-urls-for-sig
Status: VERIFIED → RESOLVED
Closed: 13 years ago → 13 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: