Register the pending input event annotator on the main thread

RESOLVED FIXED in Firefox 57

Status

()

RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Nika, Assigned: Nika)

Tracking

unspecified
mozilla57
Points:
---

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
In bug 1384238, the pending input event annotator was added, but unfortunately it was registered on the wrong thread.

This patch makes us register it on the main thread, so the annotation actually starts showing up.
(Assignee)

Comment 1

2 years ago
Created attachment 8901302 [details] [diff] [review]
Register the pending input event annotator on the main thread
Attachment #8901302 - Flags: review?(bugs)
Attachment #8901302 - Flags: review?(bugs) → review+

Comment 2

2 years ago
Pushed by michael@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/38498a94b5bd
Register the pending input event annotator on the main thread, r=smaug

Comment 3

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/38498a94b5bd
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
(Assignee)

Comment 4

2 years ago
Any chance you could take another shot at integrating this into hangs.html :)?
Flags: needinfo?(dothayer)
Should be up now. Just for my understanding - is this not feasible for the parent process? Should I keep using the old UserInteracting annotation for the parent, or do we have plans to get something similar for it at some point?
Flags: needinfo?(dothayer) → needinfo?(michael)
(Assignee)

Comment 6

2 years ago
I don't know how I would go about doing this in the parent process. Do you have some idea of what it would look like olli?
Flags: needinfo?(michael) → needinfo?(bugs)
If UserInteraction annotation uses user-interaction-active/inactive notifications, it is rather useless.
But perhaps better than nothing. However, it is very very different to pending input event check, so the UI should be different there. If it is difficult to have different kinds of UIs, perhaps parent process shouldn't have any indicator about input event handling.

I wonder if OSes have something useful here, like do they expose useful timestamps in their low level events?

What kinds of hangs do we get in parent process?
Flags: needinfo?(bugs)
(Assignee)

Comment 8

2 years ago
(In reply to Olli Pettay [:smaug] from comment #7)
> If UserInteraction annotation uses user-interaction-active/inactive
> notifications, it is rather useless.
> But perhaps better than nothing. However, it is very very different to
> pending input event check, so the UI should be different there. If it is
> difficult to have different kinds of UIs, perhaps parent process shouldn't
> have any indicator about input event handling.

That's what I'm inclined to do right now. The UserInteracting annotation does in fact use user-interaction-active/inactive and is active most of the time :-/.

> I wonder if OSes have something useful here, like do they expose useful
> timestamps in their low level events?

Yes, we do have timestamps for events at least on windows, but we don't currently have any way in BHR to go back in time and tag previously detected hangs after they have been detected. I could work on implementing that if we decide we want it though.

> What kinds of hangs do we get in parent process?

In the parent process, the majority of hangs right now are due to unnamed runnables (which are currently bugged in the UI - I filed https://github.com/squarewave/bhr.html/issues/15). 

After that, the next big lump of runnables which fail are nsPipeInputStream::Wait runnables, which seem to generally hang in nsInputStreamPump::OnInputStreamReady.
You need to log in before you can comment on or make changes to this bug.