1972965 - Denying the app links prompt leads to GeckoSession deadlock

Status: NEW

(Firefox for Android :: App Links, defect)

Description

[Jonathan Almeida [:jonalmeida]]

Attachment: actual-behaviour.mov

Prerequisite

• Ensure 'Open links in apps' is set to 'Ask before opening'.
• Ensure you have the YouTube app (easiest for triggering app links).

Steps to reproduce

1. Open to google.com.
2. Search for 'duck'.
3. In the top results, look for a youtube link.
4. Click it.
5. Observe the app links prompt asking, "Open in YouTube - Would you like to leave Firefox to view this content".
6. Select 'Cancel'.
7. All the page to load to completion.
8. Navigate back (system or app back button).
9. Observe.

Expected behaviour

• At step 9, you can scroll through the search content list, click more links, etc.

Actual behaviour

• The last paint is frozen.
• Scrolling through shows only what was initially painted, and the rest is blank.
• No links work.
• Logs show a loop of MozFirstContentfulPaint and MozAfterPaint.

Device information

• Firefox version: 141.0
• Android device model: All devices.
• Android OS version: All versions.

Any additional information?

• See attached video for reproduction.
• STR are consistent across all devices and versions.
• Reverting bug 1929028 fixes this.
• GeckoView is stuck forever sending the GeckoView:FirstContentfulPaint.
• The entire session is borked and you have to remove it.

Comment 1

[Jonathan Almeida [:jonalmeida]]

Can you verify this regression and look into setting the severity of this bug? If we're not able to fix it, we should consider backing it out during the soft freeze so it doesn't go into release.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1929028

Comment 3

[Donal Meehan [:dmeehan]]

we should consider backing it out during the soft freeze so it doesn't go into release.

The regressor landed in Fx140?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox140 (beta) and tracked for firefox141 (nightly). However, the bug still isn't assigned.

:royang, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 5

[Jonathan Almeida [:jonalmeida]]

(In reply to Donal Meehan [:dmeehan] from comment #3)

we should consider backing it out during the soft freeze so it doesn't go into release.

The regressor landed in Fx140?

From what I follow on the bug, yeah.

Comment 6

[Roger Yang [:royang]]

I'll investigate.

Comment 7

[Jonathan Almeida [:jonalmeida]]

Offline, roger found the regression to be caused by SHIP when denying the request - if we disable SHIP, the bug disappears. Since app links is the only consumer API that denies requests, it looked like an app links bug.

We both tested this on two devices with beta and will a fresh install, the bug is not reproducible, but with a second device we can still reproduce the bug, so there is a bug where the default (SHIP disabled) is probably not being used.

Comment 8

[Donal Meehan [:dmeehan]]

SHIP is enabled in Nightly only, disabled in Fx140 via Bug 1971562.
I'm not sure what the correct regressor is here?

Comment 9

[Jonathan Almeida [:jonalmeida]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #7)

..with a second device we can still reproduce the bug, so there is a bug where the default (SHIP disabled) is probably not being used.

It looks like from about:config that fission.disableSessionHistoryInParent is disable, so ship is still running in beta. I can see the SHIP beta experiment is no longer running, so there is some caching still happening.

Comment 10

[Jonathan Almeida [:jonalmeida]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #9)

(In reply to Jonathan Almeida [:jonalmeida] from comment #7)

..with a second device we can still reproduce the bug, so there is a bug where the default (SHIP disabled) is probably not being used.

It looks like from about:config that fission.disableSessionHistoryInParent is disable, so ship is still running in beta. I can see the SHIP beta experiment is no longer running, so there is some caching still happening.

Looks like I found the wrong experiment. There is still an active experiment here: https://experimenter.services.mozilla.com/nimbus/fission-android-rollout-beta/summary

I confirmed that I an indeed enrolled in that one so we can say this is no longer a beta blocker if we can end that experiment.

Comment 11

[Jonathan Almeida [:jonalmeida]]

Changing the regressor to bug 1951246. Kaya is this something you can add severity to? Should we disable ship on Nightly as well?