Fennec GeckoView hangs if Gecko isn't already running (with extension using blocking webRequest listener)

VERIFIED FIXED in Firefox 66

Status

()

defect
P2
critical
VERIFIED FIXED
10 months ago
5 months ago

People

(Reporter: pwd.mozilla, Assigned: JanH)

Tracking

({testcase})

Trunk
Firefox 67
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(geckoview64 unaffected, firefox62 unaffected, firefox63 unaffected, firefox64+ wontfix, firefox65 wontfix, firefox66+ verified, firefox67 verified)

Details

(Whiteboard: [priority:high])

Attachments

(3 attachments)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

These have stopped working over the past couple of weeks

Confirmations: https://www.reddit.com/r/firefox/comments/9ldetu/firefox_custom_tabs_not_loading/
OS: Unspecified → Android
Hardware: Unspecified → All
Thanks for the report!
Bug 1484977 is already filed for this issue (custom tabs). Please comment/follow the discussions there. 
As for page shortcuts, bug 1480793 was fixed recently. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1484977
Bug 1484977 wasn't a regression, whereas this sounds like one, in which case it wouldn't be the same issue.
I think I could reproduce it a few days ago, but at that time http://archive.mozilla.org/ had problems and so mozregression wasn't working. After updating yesterday, I can no longer reproduce this again, though.
Indeed, custom tabs were working perfectly and then randomly stopped, so not a dupe of bug 148977. 

I reinstalled and some custom tabs are working again. I need to continue testing for a difinitive answer there. 

That said, page shortcuts definitely aren't working. I had assumed that the problem was related to the custom tab problem, but no matter how many times I create the shortcut for https://my.hivehome.com/dashboard it doesn't appear.
So my further testing has uncovered that unless Firefox has been started, the custom tabs don't initiate.
[Tracking Requested - why for this release]: Custom tabs are broken when Firefox isn't already running in background

(In reply to Paul [pwd] from comment #4)
> So my further testing has uncovered that unless Firefox has been started,
> the custom tabs don't initiate.

Good point, that must have been why I couldn't reproduce yesterday. Interestingly enough, about: pages seem unaffected - these always open successfully in a custom tab even when Gecko has start from scratch.

As for page shortcuts - your example page is working fine for me, both through the PWA and the normal page shortcut route. If you can still reproduce, please open a new bug and include your phone model and OS version.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: Custom Tabs and Page Shortcuts have stopped working → Custom Tabs don't load when Gecko isn't already running
That sounds pretty bad.  Do we know when this stopped working?
(In reply to Paul [pwd] from comment #3)
> 
> That said, page shortcuts definitely aren't working. I had assumed that the
> problem was related to the custom tab problem, but no matter how many times
> I create the shortcut for https://my.hivehome.com/dashboard it doesn't
> appear.

Tried to reproduce this on the latest nightly build with Motorola Nexus 6(Android 7.1.1), Google Pixel(Android 9), LG G4(Android 6.0.1) and Xiaomi Mi4i(Android 5.0.2) but with no success. Do you have some additional steps in order to re-test and find a regression window? Thanks!
Flags: needinfo?(pwd.mozilla)
(In reply to Sorina Florean [:sorina] from comment #7)
> (In reply to Paul [pwd] from comment #3)
> > 
> > That said, page shortcuts definitely aren't working. I had assumed that the
> > problem was related to the custom tab problem, but no matter how many times
> > I create the shortcut for https://my.hivehome.com/dashboard it doesn't
> > appear.
> 
> Tried to reproduce this on the latest nightly build with Motorola Nexus
> 6(Android 7.1.1), Google Pixel(Android 9), LG G4(Android 6.0.1) and Xiaomi
> Mi4i(Android 5.0.2) but with no success. Do you have some additional steps
> in order to re-test and find a regression window? Thanks!

Strangely, I managed to reproduce this twice earlier.

First time, I was in Flamingo, I saw an article, I pressed it to read some more info and nothing happened (I was taken to the custom tab and the page remained blank), so I went into nightly manually, waited for whatever my last tab was to load, went back into Flamingo and voila!

Second time, replace Flamingo with Tumblr.

LG G6, Android 8.0.0 (August Security Patches)
Flags: needinfo?(pwd.mozilla)
Severity: normal → critical
Susheel - This seems like a bad regression and is blocking 64 - can someone please take a look?
Flags: needinfo?(sdaswani)
Vlad can you look at this ASAP.
Flags: needinfo?(sdaswani) → needinfo?(vlad.baicu)
Whiteboard: --do_not_change--[priority:high]
I also haven't had much luck reproducing this, considering that next week I am going to be on PTO, one of my colleagues is going to pick this one up Monday as a top priority.
Flags: needinfo?(vlad.baicu)
Flags: needinfo?(petru.lingurar)
Flags: needinfo?(andrei.a.lazar)
Flags: needinfo?(andrei.a.lazar)
Assignee: nobody → petru.lingurar
Flags: needinfo?(petru.lingurar)
(In reply to Vlad Baicu [on PTO until 10.29] from comment #11)
> I also haven't had much luck reproducing this, considering that next week I
> am going to be on PTO, one of my colleagues is going to pick this one up
> Monday as a top priority.

I have the tab queue enabled if that helps.

Another STR:
1. Go to Google+
2. Find a post with a link
3. Tap link to open in custom tab
4. Wait forever!
This seems to be a problem with Gecko.. View?
The issue seems similar to bug 1494748, bug 1497963 and also https://github.com/mozilla-mobile/focus-android/issues/3679 from Focus

STR to reproduce this 100% on latest Nightly:
1 - Have Fennec opened, have some pages loaded
2 - Open link as custom tab in Fennec
3 - Remove Fennec from Recents
4 - Start Fennec 
5 - Observe
- previous loaded tabs now show blank images and cannot be convinced to reload / repaint
- new tabs seem to work
- doing a drag down gesture on a blank page shows underneath the content of the last tab, even though the url and title of that blank page is different than for the last page

Small video for this - https://drive.google.com/file/d/1evRF_St5WeVKzTT7U_gOUGlB0hhvRY0o/view?usp=sharing

NIing James as this seems more like a Gecko issue.
Flags: needinfo?(snorp)
See Also: → 1494748
See Also: → 1497963
See Also: → 1500925
Duplicate of this bug: 1500925
It does look like we broke something here. Dylan, you were looking into similar problems, can you take this one?
Flags: needinfo?(snorp) → needinfo?(droeh)
Yeah, I was actually looking into this a bit on Monday afternoon. I thought it was going to just be an instance of failing to call coverUntilFirstPaint(Color.TRANSPARENT) as I think we've seen in some other cases, but it doesn't look like it's that simple: following the STR in comment 13, when I reach step 4 and restart Fennec, we do actually get the coverUntilFirstPaint(Color.TRANSPARENT) call as expected but still have a white screen. I'll investigate further.
Flags: needinfo?(droeh)
:dietrich said he is able to reproduce a similar issue (with different STR) consistently and can help with debugging
https://bugzilla.mozilla.org/show_bug.cgi?id=1494748#c15
Clearing the regression and regressionwindow-wanted keywords; I've checked periodically back to October of last year and as far as I can tell, this *never* worked. If someone has an actual working build date, please let me know.
Comment 13 confuses the hell out of me and for me personally, convolutes this bug, but using the STR in Comment 12, this was certainly working until recently.
(In reply to Paul [pwd] from comment #19)
> Comment 13 confuses the hell out of me and for me personally, convolutes
> this bug, but using the STR in Comment 12, this was certainly working until
> recently.

Interesting, there might be multiple issues here. I was basing my tests on comment 13. I'll be sure to take your STR into account as well.
Adding NI for Dylan so we don't lose momentum on this.
Flags: needinfo?(droeh)
(In reply to Dylan Roeh (:droeh) from comment #20)
> (In reply to Paul [pwd] from comment #19)
> > Comment 13 confuses the hell out of me and for me personally, convolutes
> > this bug, but using the STR in Comment 12, this was certainly working until
> > recently.
> 
> Interesting, there might be multiple issues here. I was basing my tests on
> comment 13. I'll be sure to take your STR into account as well.

Quick follow-up: I can't reproduce the issue seen in comment 12. Paul, if you have the time/inclination, logcat output from a custom tab that hangs on a white screen the way you're describing might be helpful.
Flags: needinfo?(droeh) → needinfo?(pwd.mozilla)
I've been busy today, but will try and grab a logcat for you tomorrow.
Flags: needinfo?(pwd.mozilla)
To prompt myself.
Flags: needinfo?(pwd.mozilla)
David, this might be another issue for the geckoview team once we have more info from the reporter.
Flags: needinfo?(dbolter)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #25)
> David, this might be another issue for the geckoview team once we have more
> info from the reporter.

I'm currently looking into this.
Thanks Dylan. Removing my NI.
Flags: needinfo?(dbolter)
There is a patch up in bug 1494748 so if that lands we can verify in this bug as well.
Sorry for the delay, I broke my system. Anyway, here's a logcat
Flags: needinfo?(pwd.mozilla)
Assignee: petru.lingurar → nobody
An easy and consistent way to reproduce the bug:
1. Set nightly as default
2. In settings>privacy, enable clear data on exit and choose opened tabs
3. This enables the quit button in the firefox menu
4. Exit firefox using the quit button
5. Open a custom tab through some app

Observed behaviour: nothing loads in custom tab

Intended behaviour: Site should load

This problem has been present in nightly at least since October
Blocks: 1494748
See Also: 1494748
Whiteboard: --do_not_change--[priority:high] → [priority:high]
(In reply to Leo_sk from comment #31)
> An easy and consistent way to reproduce the bug:
> 1. Set nightly as default
> 2. In settings>privacy, enable clear data on exit and choose opened tabs
> 3. This enables the quit button in the firefox menu
> 4. Exit firefox using the quit button
> 5. Open a custom tab through some app
> 
> Observed behaviour: nothing loads in custom tab
> 
> Intended behaviour: Site should load
> 
> This problem has been present in nightly at least since October

I won't dispute whether or not that can reproduce the problem as there's enough eyes on this bug already. But I would like to try and avoid the perception that this is a user issue. i.e. users are clearing data on exit or swiping the app away. This is an app issue whereby if you leave Fennec for a while and expect to load content from the web, Fennec puts a complete halt to that. It's a horrible user experience.
(In reply to Paul [pwd] from comment #32)
> (In reply to Leo_sk from comment #31)
> > An easy and consistent way to reproduce the bug:
> > 1. Set nightly as default
> > 2. In settings>privacy, enable clear data on exit and choose opened tabs
> > 3. This enables the quit button in the firefox menu
> > 4. Exit firefox using the quit button
> > 5. Open a custom tab through some app
> > 
> > Observed behaviour: nothing loads in custom tab
> > 
> > Intended behaviour: Site should load
> > 
> > This problem has been present in nightly at least since October
> 
> I won't dispute whether or not that can reproduce the problem as there's
> enough eyes on this bug already. But I would like to try and avoid the
> perception that this is a user issue. i.e. users are clearing data on exit
> or swiping the app away. This is an app issue whereby if you leave Fennec
> for a while and expect to load content from the web, Fennec puts a complete
> halt to that. It's a horrible user experience.

Well this was how ended up discovering it and posting on reddit, which i am grateful to you for reporting. The problem is that if one simply exits by back button, custom tabs will still work. Now depending on android version and variant and user settings, nightly can be cleared from background after screen locking or it may not, making it pretty inconsistent. If there is sure shot reproducible method, it becomes easier to test
(In reply to Dylan Roeh (:droeh) from comment #26)
> (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #25)
> > David, this might be another issue for the geckoview team once we have more
> > info from the reporter.
> 
> I'm currently looking into this.

Dylan, do you have any updates on this Custom Tabs issue or "content area frozen" bug 1494748?
Flags: needinfo?(droeh)
Whiteboard: [priority:high] → [priority:high][geckoview]
(In reply to Chris Peterson [:cpeterson] from comment #34)
> (In reply to Dylan Roeh (:droeh) from comment #26)
> > (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #25)
> > > David, this might be another issue for the geckoview team once we have more
> > > info from the reporter.
> > 
> > I'm currently looking into this.
> 
> Dylan, do you have any updates on this Custom Tabs issue or "content area
> frozen" bug 1494748?

The patch currently up for bug 1494748 should resolve this as well, I'm just waiting for review.
Flags: needinfo?(droeh)
(In reply to Dylan Roeh (:droeh) from comment #35)

> The patch currently up for bug 1494748 should resolve this as well, I'm just
> waiting for review.

I currently have the latest nightly from playstore and the problem is still present. Will another update implement the patch?
(In reply to Leo_sk from comment #36)
> (In reply to Dylan Roeh (:droeh) from comment #35)
> 
> > The patch currently up for bug 1494748 should resolve this as well, I'm just
> > waiting for review.
> 
> I currently have the latest nightly from playstore and the problem is still
> present. Will another update implement the patch?

The patch hasn't landed yet, so unfortunately the problem is still present on nightly. I'd recommend watching bug 1494748 for the most up-to-date information.
Duplicate of this bug: 1516922
Hello, I opened the #1516922 bug and it seems that it's a duplicate of this bug here so i post my lastest experience here.


Since the last version (or maybe before didn't tested actually) the bug only appear if there's a Adblocker module enabled.

I mean i use uBlock Origin, disabled it - force closed lastest Nightly - go to "Sync for reddit" and open a link (so it open a custom tabs) - BOUM it's working ! 

But if i enable uBlock Origin - Force close lastest nightly - go to "Sync for reddit" and open a link - it's not working, it's staying blank...
The fix for bug 1494748 was just uplifted to Fennec 65 Beta, so that might improve things in Friday's 65.0b8 release.
Whiteboard: [priority:high][geckoview] → [priority:high][geckoview:p1]
Duplicate of this bug: 1517203
Can I just confirm that despite the patch from bug 149478 landing, this bug is still a major issue.
Opps, bug 1494748 not bug 149478.
Dylan says this bug doesn't affect GV and is Fennec-specific. Dylan recommends we wait to see if the issue quiets down in Fennec 65 Beta.
Assignee: nobody → droeh
Whiteboard: [priority:high][geckoview:p1] → [priority:high]
Is it implemented in nightly channell? If it has, then i can confirm its not fixed
(In reply to Chris Peterson [:cpeterson] from comment #44)
> Dylan says this bug doesn't affect GV and is Fennec-specific. Dylan
> recommends we wait to see if the issue quiets down in Fennec 65 Beta.

Is this expected to be fixed? Because it definitely isn't running Nightly.
Yep still not fixed with 65b08 neither with the latest  nightly (still saying that the but seems to only appears when a adblocker (unlock or what ever) is active)
(In reply to timur.yildirim55 from comment #47)
> Yep still not fixed with 65b08 neither with the latest  nightly (still
> saying that the but seems to only appears when a adblocker (unlock or what
> ever) is active)

I disabled all the add ons and repeated the steps i mentioned in comment 31, and bug is still present

Dylan are you still working on this or should we hand it off to the Fennec team?

Flags: needinfo?(droeh)

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #49)

Dylan are you still working on this or should we hand it off to the Fennec team?

As far as I can see, any complete fix for this is going to be Fennec-specific and won't likely contribute to GV, so I'm going to unassign myself.

Assignee: droeh → nobody
Flags: needinfo?(droeh)

I think Jan's patch from bug 1494748 should also resolve this so this should be checked again after that patch gets merged.

It's still not solved even if the bug 1494748 was fixed on the latest nightly .. when an Adblock module is active I can't have custom tabs working if I killed Firefox nightly from the recent app

To be honest, personally I wouldn't have expected any improvement there from my patch, either.

I can confirm that the problem goes away if I disable uBlock Origin. I was testing opening a link from the Gmail app in Firefox 64.0.2 (installed from Google Play Store) on Android 9 (Pie) on a Nokia 6.1. (I also have the same problem opening links from Reddit Sync, but didn't try that with the add-on disabled.)

Duplicate of this bug: 1520992

Bug 1520992 has some more info that would fit the theory about this happening in combination with certain extensions.

While testing something unrelated, yesterday I've also experienced the case where the initial load in a custom tab would in fact work, but subsequently clicking on a link would hang. So it seems there's another bug in that the very first request might not actually be handled by the extension, which is good for this bug, but another issue in itself.

Summary: Custom Tabs don't load when Gecko isn't already running → Fennec GeckoView hangs if Gecko isn't already running (with extension using webRequest.onBeforeSendHeaders in blocking mode?)

(In reply to nandhp from comment #54)

I can confirm that the problem goes away if I disable uBlock Origin. I was testing opening a link from the Gmail app in Firefox 64.0.2 (installed from Google Play Store) on Android 9 (Pie) on a Nokia 6.1. (I also have the same problem opening links from Reddit Sync, but didn't try that with the add-on disabled.)

With my oneplus 6t on android pie the bug of a non-loading custom tabs (tabs stay white trying to load infinitly) only appear if there's a adblocking module active and firefox nightly killed from recent.. If the adblocking module is disabled , custom tabs (from sync for reddit/ gmail / all other app that use custom tabs) works great even if Firefox nightly is killed from recent .. so yeah the issue is with module handling i think

with extension using webRequest.onBeforeSendHeaders in blocking mode?

uBlock Origin does not install any onBeforeSendHeaders listener; it installs listeners only for onBeforeRequest and onHeadersReceived.

I guess any blocking webRequest listener will do...

If somebody could bundle up a minimal testcase extension along the lines of bug 1520992 comment 0, this would be appreciated.

Summary: Fennec GeckoView hangs if Gecko isn't already running (with extension using webRequest.onBeforeSendHeaders in blocking mode?) → Fennec GeckoView hangs if Gecko isn't already running (with extension using blocking webRequest listener)
Duplicate of this bug: 1524426

@lizzard
As written Firefox nightly is affected too .. so 67 if affected too

Duplicate of this bug: 1524799
Duplicate of this bug: 1524887

(In reply to Jan Henning [:JanH] from comment #59)

If somebody could bundle up a minimal testcase extension along the lines of bug 1520992 comment 0, this would be appreciated.

Never mind, I found something in the webextensions sample repository.

Keywords: testcase

There seemed to be some confusion as to how to reproduce this bug earlier in its history, unsure if that's been clarified or not yet?

Anywhere, here are a very simple set of steps that I can use to reproduce it every time (assuming an extension such as uBlock Origin is active):

  1. Press the "app switcher" virtual button on the phone (left button on Samsungs, right button on most other phones)
  2. Swipe both Firefox and its custom apps away to quit them (if any are running)
  3. Open the custom tab again
Assignee: nobody → jh+bugzilla

Once a webextension using a blocking WebRequest listener has started loading,
all network connections covered by the extension's manifest are held until the
extension is ready the process them.
One condition for the extension being ready apparently includes browser startup
having progressed far enough, as signified by "browser-delayed-startup-finished"
having been dispatched.
Therefore, we have to start sending that notification when opening a new Gecko-
View window, too, and copy Fennec's InitLater() system for that.

Unlike Fennec, we cannot tie registration of those InitLater() runnables to the
initial content load having progressed far enough because of
a) e10s, which makes that approach neither easily possible nor really sensible,
as content will load in a different process in that case, and
b) because we're racing with extension startup here - if extensions are loaded
quick enough to block even the initial page load, we'd be deadlocked: We
cannot send the notification until the page finishes loading, but the page
cannot load until we send the notification. Fennec isn't affected by the
latter problem because "sessionstore-windows-restored", which Fennec will
send in any case, serves as an alternative pathway for completing extension
startup.

And unlike Desktop, we don't really have any chrome content to paint, so we
cannot tie delayed initialisation to a paint listener for that, either.

Therefore, we simply fire off a runnable at the end of geckoview.js's
startup() method, which should give more pressing initialisation tasks enough of
a headstart.

For completeness, we're also adding the "browser-idle-startup-tasks-finished"
notification and thereby solve bug 1465832 as well, allowing the ScriptPreloader
to detect which scripts are commonly loaded during GeckoView startup and to
start caching and pre-parsing them.

Duplicate of this bug: 1465832
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/17c5a7677d9f
Dispatch commonly expected startup notifications when opening a GeckoView window. r=snorp
Status: REOPENED → RESOLVED
Closed: 10 months ago6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

So it's fixed on today nightly build ?

Yes, should be.

It's working for me now in the latest Nightly available from the play store.

Yeah seems solved for me too :) I'll make more test after work

Comment on attachment 9041877 [details]
Bug 1496684 - Dispatch commonly expected startup notifications when opening a GeckoView window. r?snorp

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

unclear

User impact if declined

For users with extensions using blocking WebRequest listeners, e.g. adblockers, pages in custom tabs/PWAs might not load if Firefox isn't already running.

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

No

If yes, steps to reproduce

Install a corresponding extension, e.g. uBlock Origin, and then follow comment #65.

List of other uplifts needed

none

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

GeckoView was merely missing a notification that was expected by other platform code (including extension startup) to detect browser window initialisation.

String changes made/needed

none

Attachment #9041877 - Flags: approval-mozilla-release?
Attachment #9041877 - Flags: approval-mozilla-beta?

Verified in comments 72 and 73.

Status: RESOLVED → VERIFIED

Comment on attachment 9041877 [details]
Bug 1496684 - Dispatch commonly expected startup notifications when opening a GeckoView window. r?snorp

Fix for a hang, verified in Nightly, let's uplift for beta 7.

Attachment #9041877 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1526677

Comment on attachment 9041877 [details]
Bug 1496684 - Dispatch commonly expected startup notifications when opening a GeckoView window. r?snorp

Glad to see this going into Fx66, but I don't think this needs to be in the dot release.

Attachment #9041877 - Flags: approval-mozilla-release? → approval-mozilla-release-

Verified on the latest version of Beta 66.0b7 using steps from comment 65.
Devices:
-OnePlus 5T (Android 9);
-Samsung Galaxy S8 (Android 8.0).

Due to that, I'll mark this issue as Verified, thanks.

Duplicate of this bug: 1528602
You need to log in before you can comment on or make changes to this bug.