1504839 - Table without data showing for multiple seconds after opening page

Status: VERIFIED FIXED

(Toolkit :: Performance Monitoring, defect)

Description

[:Harald Kirschner :digitarald]

I opened about:performance a few times where it took awkward 3+ seconds to show data; during which I already opened console to check for errors and/or pondered to close the tab again and file a bug.

AFAIK data collection happens every 5s. I assume opening about:performance in the beginning of the window, can lead lead to up to 5sec of no-data.

Quick-fix could be showing a throbber. To avoid the throbber for short loading times and to not put users into waiting mode unnecessarily, I'd recommend to experiment showing it only after 1s waiting.

Comment 1

[:Harald Kirschner :digitarald]

ni? Brian for UX input.

Comment 2

[Florian Quèze [:florian]]

(In reply to :Harald Kirschner :digitarald from comment #0)
> I opened about:performance a few times where it took awkward 3+ seconds to
> show data; during which I already opened console to check for errors and/or
> pondered to close the tab again and file a bug.
> 
> AFAIK data collection happens every 5s.

It's every 2s.

> I assume opening about:performance
> in the beginning of the window, can lead lead to up to 5sec of no-data.

In theory it should not take more than 2s to show data (ie. first data collection on load, and 2s later we have a second sample to compare with the first one, and we can display the result).

> Quick-fix could be showing a throbber. To avoid the throbber for short
> loading times and to not put users into waiting mode unnecessarily, I'd
> recommend to experiment showing it only after 1s waiting.

I also experienced today some cases where it took long enough that I opened the console to check for errors. At the time I blamed the devtools and moved on (it took a while to load when I was reloading after having made CSS changes from the devtools, and I reloaded after having saved the changes to the original file).

I think a throbber would make sense for the first 2s, if we can't make it faster than 2s. But I would also like to understand why it seems to take much longer in some cases.

Comment 3

[:Harald Kirschner :digitarald]

> I think a throbber would make sense for the first 2s, if we can't make it faster than 2s. But I would also like to understand why it seems to take much longer in some cases.

If this isn't expected, this is probably about identifying and fixing the root cause for the delay.

Comment 5

[Florian Quèze [:florian]]

Now that bug 1506589 gave me the steps to reproduce, I can say confidently that this was a regression caused by bug 1502080 and (accidentally) fixed on nightly by my patch in bug 1502951.

Here is the explanation:
- The patch in bug 1502080 makes us freeze the order for 5s after the user moves the mouse over the table body (<tbody> tag). This means that if the user moves the mouse before the first display of information (which happens 1.1s after page load) and keeps moving the mouse impatiently, the information will never be displayed.
- The patch in bug 1502951 changes the CSS and sets the height on the <table> rather than on the <tbody>, which means that before we fill in data, <tbody> has a 0px height and can't receive mouse events. This solves the problem here.

Comment 6

[Gyula Palko[:gpalko]]

Verified, that the issue is no more reproducible on Nightly 65(20181122100048) and Beta 64(20181119162153). The table on task manager page is populated even if the user is moving the mouse.