Register the pending input event annotator on the main thread

RESOLVED FIXED in Firefox 57

Status

()

Core
XPCOM
RESOLVED FIXED
9 months ago
9 months ago

People

(Reporter: Nika, Assigned: Nika)

Tracking

unspecified
mozilla57
Points:
---

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 months 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

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

Updated

9 months ago
Attachment #8901302 - Flags: review?(bugs) → review+

Comment 2

9 months 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

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

Comment 4

9 months 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

9 months 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)

Comment 7

9 months ago
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

9 months 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.