Closed Bug 1896513 Opened 4 months ago Closed 4 months ago

Firefox pdf viewer freeze after open

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Version:
Firefox 127
Platform:
All
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
128 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox126 --- wontfix
firefox127 --- fixed
firefox128 - fixed

People

(Reporter: f38382014-buzilla, Assigned: lsalzman)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [qa-triaged][fxdroid][group4] )

Attachments

(2 files)

SmartSelect_20240521_134512_Firefox Beta.jpg
74.24 KB, image/jpeg
Details
SmartSelect_20240522_135446_Device care.jpg
126.32 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Linux; Android 14; Mobile; rv:126.0) Gecko/126.0 Firefox/126.0

Steps to reproduce:

Enter to product site, click on their PDF document to read.
Pdf document list at this site
https://www.kraususa.com/kraus-kwu110-28-workstation-28-undermount-16-gauge-stainless-steel-single-bowl-kitchen-sink-2.html#reviews

Actual results:

Firefox will open pdf but freeze after open. Cannot scroll, cannot close tab, cannot go back previous page.
Only way is to get out freeze is to minimize firefox, then re open firefox.
Sometimes, after reopen, firefox would allow user to click download. Yes, download is successful. Downloaded Pdf file can be view by third party pdf app.

Expected results:

Allow user to scroll to view document.

Thanks for reporting this freezing problem.

Does this freeze happen with other PDF documents or just this Kraus PDF?

Component: General → PDF Viewer
Flags: qe-verify+
Product: Fenix → GeckoView

I had once with another site pdf document. I think it was similar issue.
I thought it was particular site but it is not.
I did not report it earlier because I just minimize and get file downloaded to view.
I have uBlock. 1st script and 3rd party script, frame block are OFF.

There is no " willReadFrequently" in gekco.

New version of FF beta still have the freeze when open pdf.
Android reports FF is not responding.

127.0b3 (Build #2016021375), hg-197cdbb72e16+
GV: 127.0-20240517091915
AS: 127.0

Version: Firefox 126 → Firefox 127

Can reproduce, after opening the PDF, it is unable to render anything. Sometimes the pdf loads, but once I scroll, the PDF blacks out. Works fine on desktop. This could potentially be the crash log:

GeckoViewProgressDelegate[C]: handleEvent: MozAfterPaint
GeckoViewProgressDelegate[C]: handleEvent: MozAfterPaint
GeckoViewProgress: receiveMessage: MozAfterPaint
GeckoViewProgress: receiveMessage: MozAfterPaint
MOZ_CRASH: [17278] Hit MOZ_CRASH(assertion failed: !(vecTangent * vecTangent < rLastTangentFuzz)) at /Users/clu/Desktop/gecko/third_party/rust/aa-stroke/src/bezierflattener.rs:824
libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 17316 (CanvasRenderer), pid 17278 (fenix.debug:gpu)
crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
tombstoned: received crash request for pid 17316
crash_dump64: performing dump of process 17278 (target tid = 17316)
DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
DEBUG   : Build fingerprint: 'google/sdk_gphone_arm64/emulator_arm64:11/RSR1.210722.013.A4/10160917:userdebug/dev-keys'
DEBUG   : Revision: '0'
DEBUG   : ABI: 'arm64'
DEBUG   : Timestamp: 2024-05-18 06:32:12-0500
DEBUG   : pid: 17278, tid: 17316, name: CanvasRenderer  >>> org.mozilla.fenix.debug:gpu <<<
DEBUG   : uid: 10196
DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
DEBUG   : Cause: null pointer dereference
DEBUG   : Abort message: '[17278] Hit MOZ_CRASH(assertion failed: !(vecTangent * vecTangent < rLastTangentFuzz)) at /Users/clu/Desktop/gecko/third_party/rust/aa-stroke/src/bezierflattener.rs:824

Looks like the same bug as 1813354 and 1805557, redirecting to the graphics team. This is affecting PDF viewing on Android.

Severity: -- → S3
Component: PDF Viewer → Graphics: Canvas2D
Product: GeckoView → Core
Summary: Firefox Default pdf viewer freeze after open → Firefox pdf viewer freeze after open due to MOZ_CRASH(assertion failed: !(vecTangent * vecTangent < rLastTangentFuzz)) at /src/third_party/rust/aa-stroke/src/bezierflattener.rs:824

There are a lot of bugs which all might be related to each other:

:calu, normally the hit assertion is only on debug builds so I'd say it's unrelated to the original issue.
That said, this assertion is a bit painful when you want to debug something...

I was not able to reproduce this on the latest Beta 127.0b4, nor on Nightly 128.0a1 from 5/21 with OnePlus 5 (Android 10), and Google Pixel 8 (Android 14).
However, Ill confirm the issue based on Comment 6.

Status: UNCONFIRMED → NEW
status-firefox127: --- → affected
Ever confirmed: true
Flags: qe-verify+
Whiteboard: [qa-triaged]

I screen captured the error from Android 14. How do I post the pic here?

Error reported from Android.

I attached screen shot in post #1

Ah I see, thanks for letting me know. I'm still not seeing any other logs that might indicate what the issue is. Are you able to reproduce this?

Flags: needinfo?(cdenizet)

I didn't manage to reproduce the bug on my device (a pixel 7 pro) with beta and the same pdf as the reporter.
I checked with the devtools to see if something is wrong but there was nothing.

Flags: needinfo?(cdenizet)

I have Samsung A7 Lite Tablet. ANDROID 14.

Sometjmes it will scroll up and down . But once you scroll it few times it will freeze.

Use the instruction manual. I think it is slightly larger file.

Hi Jamie,

We are trying to find a lead on this bug. As far as I can tell, this looks like it is happening in vendor graphics code, but don't know where to go from there. Do you know of any good leads or next steps or recommendations or where this could be redirected?

Flags: needinfo?(jnicol)

Incognito mode purple mask
No extdnsions active.

Same freeze.

Fyi

https://www.downloads.netgear.com/files/GDC/RBK863S/RBR860_RBS860_UM_EN.pdf

Tried this pdf from netgear
Furefox crashed while scrolling up and down

I don't know if this bug is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1890537 (I've the feeling it could be), but if it's the case, we've some profiles in this bug which are showing that the AndroidIU (JVM) thread is doing a lot of things when almost nothing is done on the Gecko side (or pdf.js).
I wonder if the stacks ending with org.mozilla.fenix.FenixApplication.onTrimMemory could indicate that the OS doesn't have enough memory or something like that and we're trying in Gecko to release some memory but it takes too much time, and then the OS spends too much time to empty the event queue containing the MotionEvent.

I just attached screen capture for free memory of the tablet.
Tablet has 2gb of memory.

127b4 still has the freeze. Fyi

Can you also reproduce the freeze in older versions of Firefox, like 111?

Installed this 111.1.1 arm64v8a FF
Index of /pub/fenix/releases/111.1.1/android/fenix-111.1.1-android-arm64-v8a

No, it does not freeze. But fairly slow to load pdf.
Scroll up down many times. No freeze or issues.

I need to correct that my tablet has 3 gb of memory and 2.2 gb been used when I read it from Developer option in setting.

Thanks, this is really helpful. It means there was a regression between 111 and now.

Narrowing down the regression would be even more helpful. Could you try using mozregression?

You can bisect Firefox Android builds using mozregression --app fenix or the Windows GUI app: https://mozilla.github.io/mozregression/quickstart.html

Testing the GeckoViewExample app (using mozregression --app gve or the Windows GUI app) would be more informative because you can bisect autoland builds of GeckoViewExample whereas we only had Fenix Nightly builds until very recently.

status-firefox126: --- → affected
status-firefox128: --- → affected
status-firefox-esr115: --- → affected

I just dinstalled 121.1.0 64v8a

No issue at all.

So changes happens between 121 and 125?

I do not have Windows any more... so cannot do regression.

Firefox Android switched to pdf.js in 122 release, I'm guessing that caused the change in behavior.

It has actually been enabled since 111 (see bug 1810106).
It's easy to tell: if the PDF is opened and shown in Firefox, then pdf.js is being used. If the PDF is downloaded to the phone, then pdf.js is not being used.

f38382014-buzilla to use mozregression you don't need Windows, you can also run it on Linux through the command line (preferably mozregression --app gve, otherwise mozregression --app fenix).

Is pdf.js code same in 121 and 126?

Love to try mozagression, but I have only a Android Tablet and an Iphone.

How do I get to the command line on the Android 14?

Unfortunately you need a computer to run mozregression, it cannot be done on a phone.

I can reproduce though, but not 100% reliably. On a Samsung Galaxy A10s, which has the same PowerVR GE8320 GPU as the reporter.

I got this regression range, but cannot be certain it is correct: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f486ed5f7fe28cb5ba039a627f9d227b1ed6b5be&tochange=ed817c8c33cdadf429a187a0547f154c7f09bb22

If that's the correct range, then presumably bug 1881194 is responsible. Prior to bug 1829026 canvas lived in the content process, then it was moved to the GPU process. But up until bug 1881194 it sounds like we may have been accidentally using basic shared surfaces instead of surfacetextures.

I wonder if this could be caused by bug 1894929, in which case it may already be fixed on Nightly. @f38382014-buzilla, can you reproduce in the latest nightly version?

Flags: needinfo?(jnicol) → needinfo?(f38382014-buzilla)

Hmm, actually, the latest nightly doesn't appear to contain the fix for bug 1894929 yet. So there's no point in trying that just yet.

I'll investigate this further tomorrow.

Flags: needinfo?(f38382014-buzilla)

Using mozregression with --find-fix narrowed me to this range. I couldn't get a tighter range because builds kept crashing on launch. But that contains bug 1894929!

And if I build and run current mozilla central I cannot reproduce, but if I revert bug 1894929 then I can again. So that's definitely the culprit.

This makes sense - that bug is an issue with our recycling of SurfaceTextures for webgl/canvas. (PDF.js uses canvas). It could lead to us attempting to render in to a SurfaceTexture in the canvas thread before it has been released by the renderer thread. On this GPU it appears that causes a deadlock. Or perhaps on all phones, but it’s more likely to reproduce on some due to timings. Unfortunately a debugger did not give me any useful callstacks to identify where exactly the hang occurs, but I verified this is in fact what is happening with some printfs.

So this will be fixed in the next nightly, and I'll make sure that the fix gets uplifted to beta

[Tracking Requested - why for this release]: We have received many reports for this bug, see also bug 1890537 (which is probably a duplicate of this one, and it has other two duplicates).

tracking-firefox128: --- → ?

Not a new issue in 128 so I don't think this needs tracking, but I certainly support uplifting bug 1894929 to Beta for Fx127 if we think that'll improve things here!

status-firefox126: affected → wontfix
status-firefox-esr115: affected → unaffected
tracking-firefox128: ? → -
Assignee: nobody → lsalzman
Status: NEW → RESOLVED
Closed: 4 months ago
status-firefox128: affected → fixed
Depends on: 1894929
Keywords: regressionwindow-wanted
Regressed by: 1881194
Resolution: --- → FIXED
Target Milestone: --- → 128 Branch

Let me know which 127 b? Got the fix, so I can try it and report back.

Thx

Got b6 today. Still freeze. Fyi.

Got b6 today. Still freeze. Fyi.

The fix didn’t make it in to 127b6, but will be in 127b7

127b7 fixed the issue. Thx.

Summary: Firefox pdf viewer freeze after open due to MOZ_CRASH(assertion failed: !(vecTangent * vecTangent < rLastTangentFuzz)) at /src/third_party/rust/aa-stroke/src/bezierflattener.rs:824 → Firefox pdf viewer freeze after open due
Duplicate of this bug: 1896722
Duplicate of this bug: 1891698
Duplicate of this bug: 1898295

Marco I’m not sure if they are all duplicates. Some may be. This bug may have been specific to this GPU, and caused an indefinite hang. General jank is a different problem

Bug 1896722 and bug 1891698 are no longer reproducible on Nightly, so I assume it was the same underlying problem.

For bug 1898295, I'm waiting the needinfo to be resolved. I tentatively marked as duplicate given so many people were able to reproduce this hang and are no longer able to in Nightly.

My mistake, sounds good!

Whiteboard: [qa-triaged] → [qa-triaged][fxdroid][group4]

No worries. I'm surprised too we haven't noticed this before!

Summary: Firefox pdf viewer freeze after open due → Firefox pdf viewer freeze after open
See Also: → 1898391
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: