Fennec GeckoView hangs if Gecko isn't already running (with extension using blocking webRequest listener)
Categories
(Firefox for Android Graveyard :: Custom Tabs, defect, P2)
Tracking
(geckoview64 unaffected, firefox62 unaffected, firefox63 unaffected, firefox64+ wontfix, firefox65 wontfix, firefox66+ verified, firefox67 verified)
Tracking | Status | |
---|---|---|
geckoview64 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | --- | unaffected |
firefox64 | + | wontfix |
firefox65 | --- | wontfix |
firefox66 | + | verified |
firefox67 | --- | verified |
People
(Reporter: pwd.mozilla, Assigned: JanH)
References
Details
(Keywords: testcase, Whiteboard: [priority:high])
Attachments
(3 files)
581.06 KB,
text/plain
|
Details | |
1.88 KB,
application/x-xpinstall
|
Details | |
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
ryanvm
:
approval-mozilla-release-
|
Details | Review |
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/
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
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!
Assignee | ||
Comment 2•4 years ago
|
||
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.
Reporter | ||
Comment 3•4 years ago
|
||
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.
Reporter | ||
Comment 4•4 years ago
|
||
So my further testing has uncovered that unless Firefox has been started, the custom tabs don't initiate.
Assignee | ||
Comment 5•4 years ago
|
||
[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.
Comment 6•4 years ago
|
||
That sounds pretty bad. Do we know when this stopped working?
Comment 7•4 years ago
|
||
(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!
Reporter | ||
Comment 8•4 years ago
|
||
(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)
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Susheel - This seems like a bad regression and is blocking 64 - can someone please take a look?
Comment 10•4 years ago
|
||
Vlad can you look at this ASAP.
Comment 11•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 12•4 years ago
|
||
(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!
Comment 13•4 years ago
|
||
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.
It does look like we broke something here. Dylan, you were looking into similar problems, can you take this one?
Comment 16•4 years ago
|
||
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.
Comment 17•4 years ago
|
||
: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
Comment 18•4 years ago
|
||
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.
Reporter | ||
Comment 19•4 years ago
|
||
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.
Comment 20•4 years ago
|
||
(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.
Comment 21•4 years ago
|
||
Adding NI for Dylan so we don't lose momentum on this.
Comment 22•4 years ago
|
||
(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.
Reporter | ||
Comment 23•4 years ago
|
||
I've been busy today, but will try and grab a logcat for you tomorrow.
Reporter | ||
Updated•4 years ago
|
David, this might be another issue for the geckoview team once we have more info from the reporter.
Comment 26•4 years ago
|
||
(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.
There is a patch up in bug 1494748 so if that lands we can verify in this bug as well.
Reporter | ||
Comment 29•4 years ago
|
||
Sorry for the delay, I broke my system. Anyway, here's a logcat
Updated•4 years ago
|
Comment 30•4 years ago
|
||
see bug 1494748 comment 54.
Comment 31•4 years ago
|
||
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
Updated•4 years ago
|
Reporter | ||
Comment 32•4 years ago
|
||
(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.
Comment 33•4 years ago
|
||
(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
Comment 34•4 years ago
|
||
(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?
Updated•4 years ago
|
Comment 35•4 years ago
|
||
(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.
Comment 36•4 years ago
|
||
(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?
Comment 37•4 years ago
|
||
(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.
Comment 39•4 years ago
|
||
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...
Comment 40•4 years ago
|
||
The fix for bug 1494748 was just uplifted to Fennec 65 Beta, so that might improve things in Friday's 65.0b8 release.
Reporter | ||
Comment 42•4 years ago
|
||
Can I just confirm that despite the patch from bug 149478 landing, this bug is still a major issue.
Reporter | ||
Comment 43•4 years ago
|
||
Opps, bug 1494748 not bug 149478.
Comment 44•4 years ago
|
||
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.
Comment 45•4 years ago
|
||
Is it implemented in nightly channell? If it has, then i can confirm its not fixed
Comment 46•4 years ago
|
||
(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.
Comment 47•4 years ago
|
||
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)
Comment 48•4 years ago
|
||
(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?
Comment 50•4 years ago
|
||
(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.
Comment 51•4 years ago
|
||
I think Jan's patch from bug 1494748 should also resolve this so this should be checked again after that patch gets merged.
Comment 52•4 years ago
|
||
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
Assignee | ||
Comment 53•4 years ago
|
||
To be honest, personally I wouldn't have expected any improvement there from my patch, either.
Comment 54•4 years ago
|
||
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.)
Assignee | ||
Comment 56•4 years ago
|
||
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.
Comment 57•4 years ago
|
||
(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
Comment 58•4 years ago
|
||
with extension using webRequest.onBeforeSendHeaders in blocking mode?
uBlock Origin does not install any onBeforeSendHeaders listener; it installs listeners only for onBeforeRequest and onHeadersReceived.
Assignee | ||
Comment 59•4 years ago
|
||
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.
Comment 61•4 years ago
|
||
@lizzard
As written Firefox nightly is affected too .. so 67 if affected too
Assignee | ||
Comment 64•4 years ago
|
||
(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.
Comment 65•4 years ago
|
||
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):
- Press the "app switcher" virtual button on the phone (left button on Samsungs, right button on most other phones)
- Swipe both Firefox and its custom apps away to quit them (if any are running)
- Open the custom tab again
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 66•4 years ago
|
||
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.
Comment 68•4 years ago
|
||
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
Comment 69•4 years ago
|
||
bugherder |
Comment 70•4 years ago
|
||
So it's fixed on today nightly build ?
Assignee | ||
Comment 71•4 years ago
|
||
Yes, should be.
Comment 72•4 years ago
|
||
It's working for me now in the latest Nightly available from the play store.
Comment 73•4 years ago
|
||
Yeah seems solved for me too :) I'll make more test after work
Assignee | ||
Comment 74•4 years ago
|
||
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
Verified in comments 72 and 73.
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.
Comment 78•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 79•3 years ago
|
||
bugherderuplift |
Comment 80•3 years ago
|
||
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.
Updated•2 years ago
|
Description
•