I tried to get Glimpse running on my node application for the first time but had trouble seeing Glimpse client using the following Url:
localhost:3000/glimpse/client

After several tried, a new url that finally works was
localhost:3000/glimpse/client/?baseUrl=/glimpse/client

Please take a look into it. Thanks.

Using the Node glimpse on my local machine I am getting the following error the first time a request executes (so not on start up but when I hit a route):

Tue, 13 Sep 2016 23:59:38 GMT morgan deprecated default format: use combined format at node_modules/lodash/lodash.js:12282:42
(node) warning: possible EventEmitter memory leak detected. 11 finish listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at ServerResponse.addListener (events.js:239:17)
    at ServerResponse.wrappedTransition [as on] (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/async-track/async-track.js:412:40)
    at ServerResponse.on (/Users/admin/opensource/ospo-opensource/node_modules/compression/index.js:120:20)
    at Function.MiddlewareWrapper.wrapCommonMiddleware (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/inspectors/util/MiddlewareWrapper.js:103:13)
    at wrappedMiddleware (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/inspectors/util/MiddlewareWrapper.js:152:31)
    at Layer.handle [as handle_request] (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/layer.js:95:5)
    at next (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/route.js:131:13)
    at Route.dispatch (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/route.js:112:3)
    at Route.dispatchRoute (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:17:29)
    at Route.dispatchRoute [as dispatch] (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:17:29)
(node) warning: possible EventEmitter memory leak detected. 11 headers listeners added. Use emitter.setMaxListeners() to increase limit.

I am bootstrapping from bin/www in express before any other requires run.

Node version is 4.4.7

Code appears to still work, but Glimpse doesn't fully load. I get the g icon but the rest of the bar is not there. I can click the icon and get the profiler.

Let me know what you would like me to do for further troubleshooting.

In order to reduce noise and better orient myself when viewing profiling data, its really valuable to be able to clear past data, particularly if I'm not interested in any of the historical requests. There's something physiologically valuable to knowing that everything being displayed is relevant to my current needs.

I was able to work around this by simply cycling the server, but it would be awesome to be able to clear the request list within the UI. When we did the network and performance tools in F12, this was a really common request, particularly because many similar tools provide this option for the workflow style that I mentioned above.

Edge:

• when clicked on a request, nothing happen ..

After installing the latest Mongoose, as well as Glimpse Node package, the following two logs show up in nearly all of my requests:

Neither of these are actionable for the user, so its unfortunate that the logs list could potentially get cluttered with noise, and it could be hard to know which ones represent user code or not. Having stacks for each message would be cool, but it would also be nice to just be able to completely filter out logs that came from non-user code, almost like a "just my code" for log messages.

node v6.5.0 on OSX

When I start my express app and load the first page I see this glimpse error:

Glimpse (101): Glimpse unexpected context value at location ExpressInspectorActionRouteView::onResponseRender().  Expecting context ID 72dd251077cf11e6a780919d90438b54.  Actual context ID is undefined
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onRenderComplete()
Glimpse (101): Glimpse unexpected context value at location ExpressInspectorActionRouteView::onResponseSend().  Expecting context ID 72dd251077cf11e6a780919d90438b54.  Actual context ID is undefined
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onRenderCompleteError()
{"time":"2016-09-11T03:25:55.419Z","hostname":"avi","pid":9878,"level":"error","name":"mjournal","message":"express error handler middleware","err":{"name":"TypeError","message":"Cannot read property 'hudScriptTemplate' of undefined","stack":"TypeError: Cannot read property 'hudScriptTemplate' of undefined\n    at ScriptManager.hudScript (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/messaging/ScriptManager.js:28:42)\n    at ScriptManager.getScriptTagsForCurrentRequest (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/messaging/ScriptManager.js:45:21)\n    at ExpressInspectorActionRouteView.onResponseSend (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/inspectors/ExpressInspectorActionRouteView.js:204:50)\n    at Object.listener (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/inspectors/ExpressInspectorActionRouteView.js:26:19)\n    at Tracing.publish (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/Tracing.js:30:26)\n    at ServerResponse.sendResponse [as send] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:61:35)\n    at done (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:104:22)\n    at onRenderComplete (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:88:13)\n    at Object.exports.renderFile (/Users/plyons/projects/mjournal/node_modules/pug/lib/index.js:405:12)\n    at View.exports.__express [as engine] (/Users/plyons/projects/mjournal/node_modules/pug/lib/index.js:448:11)\n    at View.render [as originalRender] (/Users/plyons/projects/mjournal/node_modules/express/lib/view.js:126:8)\n    at View.viewRender [as render] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:28:31)\n    at tryRender (/Users/plyons/projects/mjournal/node_modules/express/lib/application.js:639:10)\n    at EventEmitter.render (/Users/plyons/projects/mjournal/node_modules/express/lib/application.js:591:3)\n    at ServerResponse.render (/Users/plyons/projects/mjournal/node_modules/express/lib/response.js:961:7)\n    at ServerResponse.renderResponse [as render] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:52:35)"}}
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/main.js?hash={hash} 200 516.763 ms - 554299
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/agent/agent.js?hash={hash} 200 4.381 ms - 54744
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/context/?contextId=72dd251077cf11e6a780919d90438b54&types=environment,user-identification,web-response,web-request,after-action-invoked,after-action-view-invoked,before-execute-command,after-execute-command,after-view-component 200 1.461 ms - 5418
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/assets/glimpse-logo.png 200 0.961 ms - 810
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/assets/selawk.woff2 200 0.839 ms - 14632
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
POST /glimpse/message-ingress/ 202 16.843 ms - 8
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
POST /glimpse/message-ingress/ 202 1.189 ms - 8

If I reload the page, the app starts working correctly. This only seems to happen on the first request after app startup. The glimpse HUD is visible on the page and otherwise seems to be working.

In Data tab and Web Services tab where there is a popup from the bottom of the page, the panel is currently hidden before users select an item. When users come to this page, the UI should be like this:

We're sorry to hear you're having an issue.

We're going to do everything we can to make it right, but to be most helpful, we'd really like for you to include the following in your issue report:

• Either the steps to reproduce the issue, or a link to project which highlights the issue.
• The version of Node or .NET that you are running.
• Any pertinent error information you can give, including error message, stack trace, etc.

Please delete this boilerplate text before you hit the "Submit New Issue" button.

Requests on Glimpse Client hosted on Azure doesn't get update in real time. Please take a look into this.

I wasn't able to figure out how to get this to display in the UI, so maybe I missed it, but it would be handy to understand which middleware are attempting to change the response status code via the res.status or res.statusCode methods.

Repro steps:

1. Add a log message to one of your service's middleware/routes that logs a multi-level object (e.g. { foo: { bar: { baz: 23 } }).
2. Run the app to ensure that the above log is executed
3. Open up the Glimpse client and select the respective request
4. Select the Log sub tab
5. Expand the object in the Message column

Expected: To be able to continue expanding the subsequent "levels" of the object hierarchy
Actual: It appears to only allow expanding/collapsing the object's root level members, and then displays everything else inline, which could get hard to read if object's were logged as a result of web service calls/etc.

Awesome object visualizations was a big point of feedback when we worked on the F12 side, and is something that Chrome has done really well. This isn't super high pri, but it would be a nice-to-have for sure.

When getting to Glimpse using following url:
localhost:3000/glimpse/client/?baseUrl=/glimpse/client

Metadata server prompted twice? shouldn't it only prompt once?

It's awesome that Glimpse displays console.time/console.timeEnd intervals (I was so happy to see this!). However, there are a few things which I found somewhat strange about the way they're currently displayed:

1. Neither the From Start or Duration columns are populated, which would actually be very useful, particularly for custom time interval entries. The duration is displayed in the log message, so this isn't a blocker, but it's generally easier to read structured data in a tabular format (for me at least), instead of needing to parse the message content for relevant data.
2. Because a time entry represents an interval, and not a discrete event/message, its ordinal position in relation to other logs can make it confusing to know which logs happened between the start and end of the timer. Since it's valuable being able to correlate logs in relation to others, I could imagine it would be meaningful for users to be able to understand the relationship between a timer and its child/sibling logs. I'm not sure what the right solution would be here (E.g. Adding a "virtual" entry to the list of logs that helps you see where the call to console.timeEnd was), but in general, the mismatch between individual messages and intervals isn't completely ideal.

In practice, neither of these suggestions may actually matter to users, but I just thought I would throw it out there.

I'm probably just used to having used Fiddler, Chrome DevTools and the Edge DevTools, etc. but I found it a little odd at first that the request list is sorted descending. This was particularly confusing when a request was made as a result of a redirect, and I found it kind of unnatural to read the flow of requests bottom up.

I'm not sure I would recommend changing the default behavior (despite there being a decent amount of prior art/precendence), but it would be awesome to be able to at least change the sort direction for folks that may find it more intutuive to read the flow of requests top down as opposed to bottom up.

In /create/api/search request

There is no web services information shown but the header shows "1 request"? Shouldn't this be at "0 request"?

Repro Steps:

1. Generate a request for a document (it might impact AJAX requests as well, but I didn't test that)
2. Within the Glimpse client, select the request entry you just generated
3. Look at the response headers

Expected: To see a Connection and Date header, which confirmed in both Chrome DevTools are Fiddler are actually present present.

Actual: Every request and response header is correctly displayed, except for the Connection and Date response headers.

This is a pretty low-priority bug from my perspective, but I was confused when I didn't see these headers in Glimpse, and so I jumped to other tools to confirm. When I had worked on the F12 network tool, we had a lot of customers that would "cross check" us against Chrome and Fiddler to gain confidence in the data, so these kinds of mismatches can be meaningful sometimes to try to address.

Environment:

• Node 5.1.1
• Express 4.13.4 (I'm assuming this is a reasonably new version?)

Data filtering is always tricky, so I'm not sure if this is even the right decision, but it seems somewhat strange to see a cookie and response header in each request entry, that were introduced because of Glimpse. We did a lot of filtering in the F12 network tool, because we wanted to prevent the "observer effect" as much as possible, but I'm not sure whether that is a goal of yours. On one side, you can optimize for accuracy, ala Fiddler, and display the actual over-the-wire request/response, but I can't help but feel like Glimpse wants to be optimized for intuition/simplicity/etc., and therefore, stripping out stuff like this could be valuable to prevent unnecessary clutter.

I think this is pretty low-pri, but I just wanted to log it, since when we worked on the F12 profilers, we tended to err on the side of data filtering in order to project the most curated experience as possible, that was still actionable. For data that isn't important to end-users, we tried to remove it as much as possible.

In my super basic node application, a request was successfully executed. Texts were visible in the browser but Glimpse client did not show anything in response body tab. Here's my code for this section:

app.get('/chet', function (req, res) {
  res.send('Hello Chet!' + '<html><head>HUD Test</head><body>This is a HUD test</body></html>');
  console.log("NodeJs Works");
});

In the Debug tab, here's the message for web-response:

{
    "url": "http://localhost:3333/chet",
    "headers": {
        "x-glimpse-contextid": [
            "4a817b306fcc11e6ac0b41de37da9755"
        ],
        "x-powered-by": [
            "Express"
        ],
        "content-type": [
            "text/html; charset=utf-8"
        ],
        "content-length": [
            "772"
        ],
        "etag": [
            "W/\"304-qBlMEO+qGD9duB+6/uFbPQ\""
        ]
    },
    "statusCode": 200,
    "duration": 4.795834,
    "endTime": "2016-08-31T15:43:09.544-0700",
    "body": {
        "size": 0,
        "encoding": "utf8",
        "content": ""
    }
}

"content" doesn't seem to capture any value. Please take a look into this.

In /create/api/search request

When there is no timing information in web services tab, it shouldn't show "(NaN ms)" next to the page header.

"Date" in overview section only shows time. Please take a look into this.

• scroll bar didn't show up when hover on request/response panel in Request tab etc.
• texts do not get truncated
• alignment
• color/hover/on clicked/selected stage still need to match the latest "color spec"

The Glimpse Client shows error when selecting Web Services tab:

TypeError: Cannot read property 'duration' of undefined
eval
/Users/avanderhoorn/Projects/Glimpse.Client.Strawman/src/client/routes/requests/details/service/ServiceView.tsx
Array.forEach
(native)
ServiceTab.getMinMaxTime
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:414:23
ServiceTab.getHeaderText
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:301:39
ServiceTab.renderMaster
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:109:26
ServiceTab.render
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:94:22
ServiceTab.tryRender
webpack:///./~/react-transform-catch-errors/lib/index.js?:34:31
ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext
webpack:///./~/react/lib/ReactCompositeComponent.js?:785:34
ReactCompositeComponentWrapper._renderValidatedComponent
webpack:///./~/react/lib/ReactCompositeComponent.js?:811:32
ReactCompositeComponentWrapper.performInitialMount
webpack:///./~/react/lib/ReactCompositeComponent.js?:353:30

This application makes a large number of web service calls. The Debug tab appears to show the responses containing a duration property.

The logs feature works great for me, but there are a few things about the UI filters that I'm unclear about:

1. What does "Critical" represent? Is that a .NET idiom? Does this map to a console.* method or something else? I wasn't able to figure out how to get it to do anything.
2. Is Debug relevant? I know that the browser has a console.debug, but I had thought this wasn't available in Node? When I tried doing a console.debug, it doesn't seem to work. Is this there specifically for client-side logs? Would it make sense to hide this filter if there aren't any client-side logs? Maybe it doesn't matter, but I just wonder whether a Node dev would find this odd. Additionally, even in the browser, I believe that console.debug may be an alias for console.log, and I'm not sure how commonly used it is, so I'm curious if there's that much value it provides in general.
3. Should "Verbose" be renamed to "Logs" or something similar? The use of the term "verbose" seems kind of odd to me for some reason, especially since it maps to console.log, which I think is the standard logging mechanism, and I'm not sure whether it would be considered a "verbose mode" or not. If anything, console.debug would seem more akin to what is traditionally thought of as "verbose data", but as #2 mentioned, this isn't even available in Node. Chrome calls this "Logs" and F12 calls this "Messages", both of which I feel like are better than "Verbose". This is obviously hugely nit-picky, so take it with a grain of salt :)
4. I noticed that console.assert calls are labeled as "Errors", which is probably fine, but kind of strange, since as mentioned above, there are already filters for methods which are simply aliases (e.g. console.debug), as well as potentially unused for Node (e.g. "Critical"), so not having a dedicated filter for a first-class type of console message seems somewhat inconsistent, but not really a big deal.
5. Why do console.time / console.timeEnd pairs show up as "Verbose"? Maybe the verbose category is the catch-all? If so, then I suppose my comment #3 can be disregarded, but it would be cool to have some kind of tooltip/indication as to what "Verbose" represents.

In general, it would be awesome if the filter buttons had tooltips or something which articulated what they actually mapped to from a code-perspective, that way I could rationalize the functionality quickly.

We are currently showing only logs messages that associated with a request. I found myself using logs messages to see if my simple node app is hooked up with NodeJS correctly. The only way for me to see that log message right now is through command line. Would it be beneficial to show this information as well?

Repro Steps:

1. Add two or more web service calls to one of your app's routes
2. Run your app to exercise the above route/web service calls
3. Open up the Glimpse client and select the respective request
4. Select the Web Services tab

Expected: To see the list of web service calls
Actual: I get a React red screen of death

Interestingly, I don't get this if a request only made one web service call. However #26 occurs in that instance.

I haven't been able to determine when and why the Network, Server and Client metrics appear in the summary for a request when selecting it. Are these expected to always show up? Is there a specific attribute of a request that causes it to have this data? Apologies if this is cluttering up the issues, but I figured I would log this question in case its a bug that this data doesn't seem to consistently or reliably display.

Glimpse did a really great job capturing logs messages, however, I was left wondering of what to do next with that information ... It would be super helpful if we can allow users to click/hover on the logs message, errors logs message for example, and link back to the exact line of code that it came from.

This way, we truly are helping our users to do their job better.

In practice, I believe most devs would use console.log, since that provides the same kind of behavior as console.dir does (at least in most tools), however, there are apps that may be using console.dir from a historical perspective, and so it would be ideal if Glimpse displayed them as part of supporting the standard console API.

There is currently no hover functionality in the platform. Please take a look into this.

For insert and delete operations, the Records column is correctly populated, but I haven't been able to get it to display the number of documents returned from a MongoDB read operation.

.

Repro Steps:

1. Select a request entry within the Glimpse client
2. Copy the current URL from the browser's address bar
3. Open a new browser tab and paste the URL into it

Expected: To be navigated to the exact request that the URL points to
Actual: I get the following error, and have to navigate back to /glimpse/client and find the request again (in Chrome).

Cannot GET /glimpse/client/requests/fcbd12807b6d11e6bf4e5b3990f7f65f/request?requestAxis=headers&responseAxis=headers

Note: I can repro this issue by simply refreshing the browser tab when a request is selected, so the bug doesn't appear to be restricted to a new tab.

For requests/responses with a decent number of cookies being transmitted, it can be tricky to parse the key-value pairs when reading it as a single line. It would be awesome to have a structured visualization of this data, that was sortable by name. I'm sure this is on the backlog, so I just wanted to log it as part of my first-experience usage.

You guys already provide a richer view of form data and query strings, so having a better way to view cookies would help "complete" the core experience for profiling requests/responses in a way that many folks may be familiar with from other tools.

Currently when there is nothing found in Request body/ Response body nothing shows up. We can show simple messages saying "No body response found" etc.

This behavior should also applied in other places in the platform where we cannot generate information.

Log messages are expandable when their content represents an object, however, if the content is a string with newlines in it (e.g. a stack), then there doesn't appear to be any support for this, which makes it hard to parse. For example, if you run a failing assert (or console.trace), that will generate a stack log, which Glimpse displays, however, its pretty unreadable:

If you look at the contents of this string within the DOM, it has the expected newlines, but those aren't being correctly handled in the UI in order to make the data more easily readable.

Repro steps:

1. Add an insert and/or delete operation for MongoDB into one of your app's routes
2. Run the app in order to exercise the insert/delete call
3. Open up the Glimpse client and select the respective request
4. Select the Data tab
5. Select the insert/delete operation

Expected: To see the data that was inserted or deleted from the DB
Actual: The Command section is empty.

.

Update (9/15/2016 - 4:48 PM): I updated to the new glimpse-node umbrella package, and the NaN issue displayed below is fixed, but I still don't see the actual service call in the list.

Repro steps:

1. Add a call to http.get (or http.request, or any "higher-level" library which uses them under the covers) within one of your app's routes.
2. Run the app in order to exercise the code that generates the above GET request
3. Open up the Glimpse client and select the respective request
4. Select Web Services tab

Expected: To see the get request
Actual: The get request isn't displayed, however, the heading bar displays "1 Requests".

If I open up the dev tools, I can see an error logged that may be the source of the issue, so this may not be specific to http.get, but rather, simply an issue with the web services UI in general.

Update (4:01 PM 9/19/2016) - This same issue impacts the res.links method as well, and has the same odd display as the res.cookie method.

Repro steps:

1. Write a cookie from within a middleware (e.g. res.cookie("foo", "bar"))
2. Write the exact same cookie from within a different, but subsequent middleware (they don't need to be adjacent in the middleware pipeline)
3. Run the app to exercise the cookie changes
4. Open the Glimpse client and select the respective request

Expected: To see the cookie as being set from both middleware
Actual: Glimpse shows the later middleware as having set the cookie twice, and it crosses out the cookie being set from the previous middleware. Since both cookies are being sent across the wire, I don't know if it makes sense to cross one of them out. And the fact that the later middleware is depicted as having set the cookie twice seems misleading.

Most of the time that I'm using the client, I want to inspect the most recently made request, so it would be a small, but nice experience to have the UI auto-select the first request for me. This behavior would also likely help the first impression of the tool, by populating the UI with data, instead of just seeing a mostly blank screen.

Ideally, we could add the same behavior to all master/detail views (e.g. the Data tab) as well, to provide a consistent experience that makes navigating around the UI "feel" a little smoother. When we added this feature to many of the F12 tools (as applicable), we were surprised how it impacted people's perception of the product, especially on first load.

Most web devs probably know what a 200, 404, 500 etc. are, but the distinction between a 301 and 304 can be subtle for folks, and so displaying the "friendly name" in addition to just the actual status code can be pretty helpful (e.g. Moved Permanently vs. Not Modified).

This is definitely a nice-to-have, but it was something we did in the F12 network tool based on feedback, and we found it to be a simple improvement, somewhat similarly to how the Glimpse client displays a "friendly name" for well known middleware.

Repro steps:

1. Add a MongoDB call to an app's route (I'm using Mongoose, but it shouldn't matter)
2. Run the app to exercise that call
3. Open up the Glimpse client and select the respective request entry

Expected: To see the Query/Count metric reflect the single Mongo call and its duration.
Actual: The metric simply displays 0ms / 0

If I select the Data sub-tab, I do in fact see the Mongo call and its duration, so it just seems to be an issue with the request metric in its summary pane. Apologies if I'm misinterpreting what this metric is meant to represent.

Repro steps:

1. Open up the Glimpse client in IE or Edge

Expected: To see the list of requests
Actual: The client UI appears, but the request list is empty

The client works perfectly in Chrome, so the issue appears to be limited to IE/Edge. When I open up the dev tools, there is an error in the console, so maybe the databinding logic doesn't work currently in IE/Edge?

.

I'm sure this is already planned for accessibility/etc., but as a "keyboard-preferred" user, I just wanted to log the request to be able to fully navigate the UI via the keyboard. For my use-cases (and many of users), this would dramatically improve the usability. As a data point, this is actually one area where we "won" over some users to F12, because our tools were much more keyboard friendly than Chrome's were at one point. They've improved this significantly, so I'm not suggesting that it's a differentiating point, but it became very clear to us from working with many devs that keyboard nav is a not just a valuable feature, but a "table stakes" experience that is expected by many users.

• Under Overview section, "Total request time" is misspelled
• Under Overview section, , when value is null/zero, we can say "none" instead of "undefined ms". This could apply to all item in the Overview section.

Navigating to /glimpse/client/?baseUrl=/glimpse/client appears to do nothing in Safari. You will be prompted (once) to select the metadata URI, but using the default does not result in a page being shown. The console window shows the following error:

[Warning] Invalid CSS property declaration at: ; (main.css, line 920)
[Error] TypeError: window.fetch is not a function. (In 'window.fetch(metadataUri)', 'window.fetch' is undefined)
    (anonymous function)
    (anonymous function)
    (anonymous function)
    onEnter
    (anonymous function)
    (anonymous function)
    (anonymous function)
    next
    loopAsync
    runTransitionHooks
    runEnterHooks
    (anonymous function)
    runTransitionHooks
    runChangeHooks
    finishMatch
    (anonymous function)
    next
    loopAsync
    matchRoutes
    match
    (anonymous function)
    listen
    listen
    Router_componentWillMount
    performInitialMount
    mountComponent
    mountComponent
    performInitialMount
    mountComponent
    mountComponent
    performInitialMount
    mountComponent
    mountComponent
    performInitialMount
    mountComponent
    mountComponent
    mountComponentIntoNode
    perform
    batchedMountComponentIntoNode
    perform
    batchedUpdates
    batchedUpdates
    _renderNewRootComponent
    _renderSubtreeIntoContainer
    render
    render
    eval code
    eval
    (anonymous function) (bundle.js:59)
    __webpack_require__ (bundle.js:20)
    eval code
    eval
    (anonymous function) (bundle.js:50)
    __webpack_require__ (bundle.js:20)
    (anonymous function) (bundle.js:40)
    global code (bundle.js:41)

I'm not even sure whether what Glimpse already shows for Mongo operations isn't sufficient, but I couldn't help but wonder whether the difference between Mongoose code and the underlying MongoDB protocol operation couldn't be confusing (or at least non-ideal) for some users. For example, in my app, I have the following code:

Todo.find({ user_id : user_id }).sort( '-updated_at' )

Which translates into the following within Glimpse:

{ "find": "admin.todos", "limit": 0, "skip": 0, "query": { "user_id": "2YgMPUBERMIRrRyYLWQLfbMFBNb7YolP" }, "sort": { "updated_at": -1 }, "slaveOk": false }

It's pretty straight forward to map between the two, but you'll notice that the syntax for specifying sort direction is different, the query is targeting the "raw" collection as opposed to my model object (Todo), and I didn't specify any paging, so seeing the limit and skip fields may seem superfluous.

In practice, this might not be a big deal at all, but since we're generally striving to provide an app-specific view of execution, in a way that is as semantically rich and as close to what developer's are familiar with as possible, it seems worth investigating whether doing something to light up Mongoose-based apps would be valuable for folks or not.

This is a pretty minor issue, but since error messages display the red icon, it would be great if users could visually scan their logs for issues, without seeing any false negatives.

Repro steps:

1. Add a call to console.trace into your app
2. Run the app to exercise the code that calls #1
3. Open up the Glimpse client and select the respective request in the list
4. Select the Logs tab

Expected: To see the call to console.trace, displayed as an informational message
Actual: The trace call shows up, but it is labeled as an error.

This is what I got when I double click on a request!!

After using Glimpse a little bit over the last couple of days, I keep finding it somewhat disorienting that it doesn't display static assets anywhere. I really like the "focused" view that Glimpse is providing, but if a Node server is setup to actually receive and serve static assets (as opposed to delegating that to a reverse proxy such as nginx), then it seems a little odd (for me at least) for that traffic to be entirely omitted from the UI. I think I agree with not showing these requests by default, but I can't help but feel like it would be valuable to allow the end-user to choose to see them somewhere, if for nothing else than to be able to "cross check" what the tool is showing them, and feel comfortable with the data.

When we re-built the network tool in F12, we had a lot of users compare us against Fiddler or Chrome's network tool, and I suspect that Glimpse might receive similar comparisons. The lack of static assets is definitely an obvious divergence.

Personally, I think it would be pretty awesome if static assets were displayed either as child rows within the request list (if that list was turned into a tree), or if there was a new tab added to the request details page that displayed the child requests that were made as a result of it. I may be alone in wanting to see this, based on having used traditional web tools for a long time, but I just wanted to log this perspective as a first-time user.

In order to spot potential performance optimizations, it would be pretty awesome to see whether a database call was using an efficient index or not, based on seeing the difference between the number of documents returned and the number of documents scanned. This may be a little low level, but it seems like folks use the explain method to help identify these kinds of opportunities "manually", so having Glimpse do it for you could be pretty cool. That way, you're not just relying on the duration of the database call to know if its efficient.

When I have a lot of requests in the left panel, I found myself spending a lot of time looking through each one to see which one I should be investigating. This is not very helpful.

After discussing with Phil, I would like to purpose a simple way to get around this problem:

1. We can show number of total time. In case where a request is taking long time, we can show "in progress" instead of don't show anything.

1.2. Add error/warning icon in front of status number. This will base on status code semantic (for example, 404 = error) as well as what's being generated in logs tab. For example, GET 200 is not an error but there is an error message in the logs tab for the associated request, therefore warning icon appear next to the GET 200 status code. We can limit this behavior to only warning and error.