1847566 - Investigate How Focus is set in GeckoView Concerning `primary` Gecko Browser Attribute

Status: NEW

(GeckoView :: General, task, P3)

Description

[Olivia Hall [:olivia]]

When working on bug 1809422 an issue was occurring where setFocused was set to true when pressing the web content, then set to false when leaving the content, and not setting back to true when visiting the content.

When calling setFocused, the Gecko browser is set to primary/non-primary here. For the original bug, this causes this to not return a canonical browsing context because the browser was non-primary.

For example, the bug was:

1. Touch the content on tab 1 (tab 1 becomes primary = true ).
2. Navigate to a new tab 2, (tab 1 becomes primary = false) and don't touch the content on new tab 2. (If the content is touched on tab 2 and then switched back to tab 1, then the bug will not occur.).
3. Navigate back to tab 1, and don't touch the content on tab 1 (tab 1 stays primary = false).
4. Try to print and it will fail due to no browsing context.

Bug 1809422 was solved by calling setFocused to true before printing because it seemed like the safest option. However, when working on this bug it was unclear if the focus behavior in Fenix was fully correct. In GVE, focus is changed on each tab change, unlike Fenix. In Fenix and GVE, setActive was always called. It does seem okay if setActive and setFocused are in different states based on the documentation.

This bug is to investigate if focus in Fenix is behaving as expected or if it is a deeper issue. It might also be possible that the primary/non-primary flag should be set to always primary or even possibly relates more to the setActive call. The primary call was originally always set to true before this time. The test suite also continues to pass if these primary/non-primary sets are removed and the browser always remains primary.

Paraphrasing some info from Nika: Desktop uses the primary marker to determine which tab has an active browser in a window. Each browser window has one primary browser, which is the selected tab. Android does not share AppWindows between tabs.

Android follows a one window = one tab pattern, so it seems like Android should always have the window/singular tab set to primary.

Edit: I think this documentation is related:

Priority Hint
The way this is implemented is by setting the active property on the browser object to false, which causes Gecko to de-prioritize the process, assuming that no other windows in the same process have active=true. See also GeckoDisplay.

I think the root of this investigation might just be making sure setActive should not be the one also setting primary=true/false. The calls were one and the same at one point.

Comment 1

[Zac McKenney [:zmckenney]]

:kaya This seems like something you might want to be aware of.

Comment 2

[Kayacan Kaya [:kaya]]

Thanks :zmckenney for bringing this up! I was aware of this issue when it first got implemented for fixing the pdf bug linked above. Thanks :olivia for the detailed walk-through. I totally agree with your points.
Getting rid of setFocused callback on the save pdf layer and moving primary field setting back to setActive callback sounds like a good idea. The setActive callback will be triggered at every tab navigation back&forth regardless of touching/focusing to the visible tab, and because of this, the linked pdf bug should also be addressed by that change.