Ensure APZ keyboard handling works properly with compositor resets

RESOLVED FIXED in Firefox 57

Status

()

defect
P3
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: kats, Assigned: rhunt)

Tracking

57 Branch
mozilla57
All
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(In reply to Martin Stránský from bug 1377950 comment #19)
> There's also a crash after the restart when keyboard is hit:
> 
> Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
> 0x00007fffe0b6860f in mozilla::layers::FocusState::IsCurrent
> (this=0x7fffb4eae8a8)
>     at /home/komat/tmp676-trunk-gtk3/src/gfx/layers/apz/src/FocusState.cpp:31
> 31	  MOZ_ASSERT(mLastContentProcessedEvent <= mLastAPZProcessedEvent);


This seems like a bug. If the GPU process restarts mLastAPZProcessedEvent can get reset to a smaller value than mLastContentProcessedEvent. We should have some mechanism for handling this better.
Priority: -- → P3
Assignee

Comment 1

2 years ago
I wasn't able to reproduce this when debugging bug 1377950. But it seems entirely possible. I'm going to try it on windows too to see if I can reproduce it.

I'm guessing we can reset the content process focus number to 0 when the compositor/APZCTreeManager is deleted and brought back.
Assignee

Comment 2

2 years ago
I should also note that this isn't just with the compositor process, and could theoretically happen with a device reset, which bug 1377950 kind of is.
Summary: Ensure APZ keyboard handling works properly with compositor process resets → Ensure APZ keyboard handling works properly with compositor resets
It's 100% reproductible for me:

1) launch browser with only one tab with some internal content inside (about: or "session restore" page after browser start)
2) restart compositor (ALT+F2, type r on gnome-shell)
3) hit ALT+L on browser (I tried to open a new page after compositor restart)

I got that when working on Bug 1377950 - when only internal page is loaded the the compositor restart does not "blank" it, instead I get the keyboard ASSERT() crash.
Assignee

Comment 4

2 years ago
(In reply to Martin Stránský from comment #3)
> It's 100% reproductible for me:
> 
> 1) launch browser with only one tab with some internal content inside
> (about: or "session restore" page after browser start)
> 2) restart compositor (ALT+F2, type r on gnome-shell)
> 3) hit ALT+L on browser (I tried to open a new page after compositor restart)
> 
> I got that when working on Bug 1377950 - when only internal page is loaded
> the the compositor restart does not "blank" it, instead I get the keyboard
> ASSERT() crash.

Okay those instructions work for me, I'll work on a fix now.
Comment hidden (mozreview-request)
Reporter

Comment 6

2 years ago
mozreview-review
Comment on attachment 8895979 [details]
Bug 1388466 - Sync focus sequence numbers when the compositor is reset.

https://reviewboard.mozilla.org/r/167252/#review172482
Attachment #8895979 - Flags: review?(bugmail) → review+

Comment 7

2 years ago
Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1bcc26dc569d
Sync focus sequence numbers when the compositor is reset. r=kats

Comment 9

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/1bcc26dc569d
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57

Updated

2 years ago
Depends on: 1405878
You need to log in before you can comment on or make changes to this bug.