792888 - [Telemetry front-end] Some Firefox UI functionality is blocked for minutes on end while the data loads

Status: RESOLVED FIXED

(Mozilla Metrics :: Frontend Reports, defect)

Description

[Justin Lebar (not reading bugmail)]

STR:

* Open http://bit.ly/memorytelemetry.  If this loads immediately, switch one of the parameters on the left-hand side (e.g., switch to viewing "aurora" data), so that it has to load for a while.

* While the page is loading, click the new tab button or press "ctrl+L" (to focus the location bar).

Results: Clicking the new tab button and pressing ctrl+L do nothing.

I have no idea what the telemetry front is doing to cause this, but since uncached load times can be upwards of 10 minutes, this makes it basically impossible to use the browser while loading uncached results.

I have some Aurora data that I would like to see, but I literally cannot pull it up, because the report is so slow to generate, and my browser is only half-functional while the report is loading.

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

This sounds like both a problem with the Telemetry frontend and the browser, which shouldn't lock up on page load. Do you have any data in about:telemetry on what caused the hang? We should also try to profile with the SPS profiler.

Comment 2

[Justin Lebar (not reading bugmail)]

I also found that the data doesn't actually load after one of these really long intervals.  I have to close the tab and re-open it, which loads the data from the telemetry system's now-primed cache.

Comment 3

[Justin Lebar (not reading bugmail)]

> This sounds like both a problem with the Telemetry frontend and the browser, which shouldn't lock up 
> on page load.

You can trivially lock up the whole browser UI with |while(1) {}|.  Our only mitigation against that is the un-responsive script dialog.  I believe that dialog popped up in the past and I said "ignore" because the browser somehow remained mostly responsive.

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

That's a rather good point. Interestingly, while loading the report as you describe in comment 0, I am able to change tabs, interact with content, and use the menus. I cannot create a new tab as you stated.

Comment 5

[Pedro Alves]

There seems to be 2 separate issues here:

1. We'll try to look what's causing the UI to block. I suspect blockUI (though I have no clue why a script would even be allowed to stop the interface)


2. We'll turn on the query monitorization - 4 minutes is absolutely unacceptable! Has to be more like 4 seconds..

Comment 6

[Annie Elliott]

https://metrics.mozilla.com/projects/browse/BIV-91

Comment 7

[Pedro Alves]

Forgot to mention - we did a bunch of optimizations and I don't expect at all any query to take "minutes"

Comment 8

[Justin Lebar (not reading bugmail)]

>  we did a bunch of optimizations and I don't expect at all any query to take "minutes"

It's much faster now.  Going to http://bit.ly/memorytelemetry and switching from nightly --> aurora (on a cold DB cache) takes roughly 45s, as opposed to many minutes.

But I still don't think this bug is fixed, even if 45s is an acceptable amount of time to wait for data, because the browser UI is still blocked for 45s.

(In reply to Pedro Alves from comment #7)
> Forgot to mention - we did a bunch of optimizations and I don't expect at
> all any query to take "minutes"

Are you still planning to track query times, like you suggested in comment 4 (2), so we don't have to guess how long queries are taking?

Comment 9

[Pedro Alves]

We are tracking time, and I'm not implying the blocked ui isn't a bug, we'll tackle that early next week

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

The related Jira issue has been resolved fixed. Can this bug be closed?

Comment 11

[Justin Lebar (not reading bugmail)]

This seems to work for me.