Open Bug 1890537 Opened 5 months ago Updated 3 months ago

Firefox nearly froze when I zoomed in in this PDF

Categories

(GeckoView :: PDF Viewer, defect)

Product:
GeckoView
Component:
PDF Viewer
Platform:
All
Android
Type:
defect

Tracking

(Performance Impact:medium)

Project Flags:
Performance Impact medium

People

(Reporter: julienw, Unassigned)

References

Details

(Whiteboard: [fxdroid] [group4])

STR:

  1. Open https://ffessm-ctr-aura.fr/wp-content/uploads/2018/03/GTOrdinateurs-1.pdf
  2. Zoom in.

I'll do a profile and may precise the STR more later, but wanted to open it already.

Flags: needinfo?(felash)

I'm not only zooming in; I need a combination of zooming in, zooming out, scrolling etc.
Then there are big delays and janks sometimes. And occasionnally a big freeze...

So here are a few profiles:

Yesterday normal zoomin/zoomout/scrolling, Nightly preset: https://profiler.firefox.com/public/33krvaddt32343w5ytj9rja2kag3tmnhq35vs98
^ in that one we see ublock doing crazy stuff, but this miught be a red herring because I don't see it in the next ones.

Normal zoomin/zoomout/scrolling without freeze, Nightly preset: https://share.firefox.dev/4cUtito
Just before a freeze (the freeze is in the last ~2 seconds), Graphics preset: https://share.firefox.dev/49xqpfh
During the freeze, Graphics preset: https://share.firefox.dev/3xHtKeo
During the freeze, Nightly preset without screenshots: https://share.firefox.dev/3vN8kvY

Flags: needinfo?(felash)
Severity: -- → S3
See Also: → 1891698
Duplicate of this bug: 1891698
See Also: 1891698 →

As explained in duplicate bug 1891698, I experience the same issue on my Fairphone 3 device running Android 13. I can reproduce with the PDF shared by [:julienw] and also with this PDF when zooming in/out of the QR code area. Here is my about:support. Here are a few profiles that I managed to capture.

Profiles when zooming on the QR code area:

https://share.firefox.dev/4cVSEr3 (Nightly 126)
https://share.firefox.dev/4cZBoRz (Nightly 126, no screenshots / missing GPU?)
https://share.firefox.dev/4aWx0Bi (Nightly 127, no screenshots / missing GPU?)
https://share.firefox.dev/3UjK7XK (Nightly 127, + many threads + IPC)

Profile when zooming on another text area of the same document, which still produces unresponsiveness but seems more easily recoverable maybe:

https://share.firefox.dev/4cQsW7c (Nightly 126)

Performance Impact: --- → ?

This is easily reproducible with PDFs, but it doesn't seem directly related to the PDF integration in Firefox as it is also reproducible on the web viewer at https://mozilla.github.io/pdf.js/web/viewer.html.

See Also: → 1838865
Duplicate of this bug: 1898295

Is there anything we can do on the android side, if this is reproducible on pdf.js? If not, we should close this as WontFix.

Flags: needinfo?(mcastelluccio)

Yes, this bug is more easily reproducible with pdf.js, but it is a bug in Gecko.

Flags: needinfo?(mcastelluccio)

Yannis, Julien, are you able to reproduce this on older versions of Firefox? I'm trying to figure out if this is the same as bug 1896513.

Flags: needinfo?(yjuglaret)
Flags: needinfo?(felash)

Firefox 126 is the current stable, do you have a way to test in an earlier version?
I tested in 126 stable and see the issue.

Frankly I see the issue with more PDF. For example with https://www.osureunion.fr/wp-content/uploads/2022/03/pdf-exemple.pdf which looks pretty simple. If I zoom in a lot, then scroll, I get these huge unresponsiveness. (sometimes I need to zoom in / zoom out / zoom in repeatidly)

If I had to make a guess, I'd say this could be because of canvas handling. Indeed when zooming in the canvas is enlarged so that the full pdf is still present, and (maybe? but I'm not sure) the full PDF is still rendered even in the parts that are not visible.
When the canvas is large this takes a lot of memory, and I believe this is a problem in devices that don't have a lot of memory.
We don't see it well in the profiler profiles because I believe the memory is some special memory (maybe the GPU memory? I'm not sure, Graphics folks should be able to tell you more). There could be other ways to look at the full taken memory, again the Graphics folks should know more, and we could be able to validate or invalidate this guess.

Another possibility (coming from the fact we need sometimes to zoom in / zoom out repeatidly to trigger the problem) is that we're leaking some data when doing that. Maybe some data is kept in a structure and never cleaned up.
Hopefully the profiler with "allocations" should be able to tell more about that.

If the big canvas is the problem indeed, then we should stop this big canvas implementation, and instead we should have a small canvas that takes just the screen, that we can pan around and redraw as the user pans in it.
There are several issues with that of course: in the current implementation I believe we're not redrawing on pan, and redrawing is costly if we redraw everything, so we'd need to have a way to know what exactly we need to redraw for which coodinates...
This could be a mode happening above some zoom level too. Maybe until 400% we can keep doing what we're doing.

Then there's an issue with the scrollbars: they're not present anymore. On Android this isn't a big deal because we don't use them, but this might be on desktop. But on desktop this problem is less present so maybe the implementation could be different.

Flags: needinfo?(felash)

You can use mozregression --app gve (preferably), or mozregression --app fenix.

(In reply to Marco Castelluccio [:marco] from comment #11)

You can use mozregression --app gve (preferably), or mozregression --app fenix.

Thanks, I can look at doing that on monday. Therefore I'm adding the NI back.

Flags: needinfo?(felash)

It seems that I can always repro freezing even with version 100 if I do enough pinching/zooming/scrolling. So it could be occurring as we stack pinch/zoom/scroll events, with each event getting answered too slowly we stack up more computations until we are unable to respond at all. This makes the issue quite hard to bisect: even though I feel like it's easier to get the freeze with more recent versions, I'm never sure if I reach it because it's the issue we're looking for or because I tried too hard to get it. I know that's not super helpful... Curious to read how it goes for [:julienw].

Flags: needinfo?(yjuglaret)

I'm a bit puzzled by bug 1896513 comment 32 because running mozregression --app gve --good 100 --bad 127 opens up a version of GeckoView for 100 where the PDF opens in GeckoView itself. Is that weird?

(In reply to Yannis Juglaret [:yannis] from comment #14)

I'm a bit puzzled by bug 1896513 comment 32 because running mozregression --app gve --good 100 --bad 127 opens up a version of GeckoView for 100 where the PDF opens in GeckoView itself. Is that weird?

That's strange! It should only have been available starting from 111.

Flags: needinfo?(cpeterson)

:julien or :yannis, in nightly, could you set gfx.canvas.accelerated to false and try again ?

Flags: needinfo?(cpeterson)

(In reply to Calixte Denizet (:calixte) from comment #16)

:julien or :yannis, in nightly, could you set gfx.canvas.accelerated to false and try again ?

For me I would say that this seems to solve the issue.

With gfx.canvas.accelerated set to true: as I pinch/zoom/scroll, Firefox gets more and more unresponsive to pinching/zooming/scrolling (like it's still processing each previous event), until it eventually freezes. I can reach a point where Android kills Firefox and says that Interface and system are not responsive.

With gfx.canvas.accelerated set to false: as I pinch/zoom/scroll, Firefox stays mostly responsive to pinching/zooming/scrolling, what's shown on screen is often only very partially correct (e.g. only the background colors) but if I stop at any point and wait for rendering to finish, Firefox eventually recovers and renders properly.

Bug 1896513 is fixed in Nightly, could you test again with latest Nightly? If it is fixed for you too, we can duplicate this bug to that bug.

(In reply to Yannis Juglaret [:yannis] from comment #17)

(In reply to Calixte Denizet (:calixte) from comment #16)

:julien or :yannis, in nightly, could you set gfx.canvas.accelerated to false and try again ?

For me I would say that this seems to solve the issue.

With gfx.canvas.accelerated set to true: as I pinch/zoom/scroll, Firefox gets more and more unresponsive to pinching/zooming/scrolling (like it's still processing each previous event), until it eventually freezes. I can reach a point where Android kills Firefox and says that Interface and system are not responsive.

With gfx.canvas.accelerated set to false: as I pinch/zoom/scroll, Firefox stays mostly responsive to pinching/zooming/scrolling, what's shown on screen is often only very partially correct (e.g. only the background colors) but if I stop at any point and wait for rendering to finish, Firefox eventually recovers and renders properly.

I see the same thing exactly.

I have latest nightly in play store, its gecko view is from May 22, so in theory it should have the fix from bug 1894929 (landed May 20).
Unfortunately I still see the same issue with this version :/
But let's wait until the next Nightly to be sure.

Adding Jamie for visibility, in case it is still indeed reproducible.

Unfortunately I still see the same issue with this version :/

I tried again now and it looks like it behaves a bit better. I'll report again in a few days.

I would also say it's better, definitely feels more usable at least. I still get freezes (especially with the train ticket PDF), but Firefox seems to recover more easily from them than before, it does not get killed outright. I can manage to get it killed if I continue pinching/zooming/scrolling.

Do you still see a difference when setting gfx.canvas.accelerated to false in latest Nightly? Is it behaving better or the same?

It's a bit hard to say. I would say the freezes can maybe last longer when set to true but neither setting is really super good.

Recording with gfx.canvas.accelerated set to true here. AURA PDF yields recoverable freeze at 0:31-0:37. Train ticket PDF yields 24 seconds freeze at 1:04-1:28, after which Firefox recovers but Android says Firefox is not responsive.

Recording with gfx.canvas.accelerated set to false here. AURA PDF yields recoverable freezes at 0:42-0:55 and 1:10-1:21. Train ticket PDF yields recoverable freezes at 1:35-1:40 and 2:13-2:18.

No longer duplicate of this bug: 1891698
No longer duplicate of this bug: 1898295

I tried again today with latest nightly (v128 20240602092157).
The PDF from comment 10 works fine now.

The PDF from comment 0 works a lot better. I don't seem to get these hangs anymore (note: I be
lieve they were symptoms of the phone using the swap), however I still get OOM crashes without any crash report.

From logcat we clearly see that my Android OOM killed every other app before killing Fenix (and the GPU process and the tab process).

Also sometimes just the GPU process is killed (we can see that when the tab gets fully black).

Flags: needinfo?(felash)
Whiteboard: [fxdroid] [group4]

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Android
Impact on site: Causes noticeable jank
Resource impact: Severe

Performance Impact: ? → medium
You need to log in before you can comment on or make changes to this bug.